[NEWSboard IBMi Forum]
Seite 2 von 2 Erste 1 2
  1. #13
    Registriert seit
    Oct 2019
    Beiträge
    16
    Wenn die ISO8601 Timestamp auf 'Z' endet bedeutet dass das die Timestamp in UTC Offset 0 ist. Wenn man also so eine ISO8601 Timestamp für beliebige RPG Timestamps erzeugen will und das System auf CET eingestellt ist muss man dank der Sommer/Winterzeit die Timestamp um ein variables UTC Offset korrigieren. mktime verwendet die TZ Database und kann darum ermitteln was das UTC Offset war als die Timestamp entstanden ist (außer bei der Stunde Überlappung beim Übergang von Sommer- zu Winterzeit). Wenn mans also richtig machen will, reicht simples formatieren der Timestamp nicht.

  2. #14
    Registriert seit
    Sep 2005
    Beiträge
    385
    Hier hat Birgitta schon einmal was zu den Zeitzohnen gesagt:
    #3

  3. #15
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Da man das mit der Zeitzone ja weiß, konnte man dies ja schon füher in der DB durchaus berücksichtigen, wenn diese Info benötigt wurde.
    Ein Timestamp kann schon immer mittel QUTCOFFSET aus der Systemzeit die UTC-Zeit errechnen und in der DB speichern. Das geht nun mal nicht mit "current timestamp" per SQL oder %Timestamp().
    Die jeweils aktuelle Zeitzone konnte man ebenso separat speichern.
    Dies nun als spezielles Timestampwithzone-Feld zu entwickeln halte ich persönlich für nicht erforderlich, da es damit auch zu Inkompatibilitäten kommen kann.
    Bei vernünftigem Design (wie Dieter immer schön sagt) hätte man das Problem nie gehabt;-).
    Einfach nur UTC-Zeit sowie UTCOFFSET speichern und alles ist ok.
    Auch mit %Minutes() und %Hours() lässt sich aus QUTC dann die UTC-Zeit errechnen

    In Unix z.B. gibt die Zeitfunktion immer die Anzahl Sekunden seit 1.1.1970 in UTC zurück, also damals schon berücksichtigt.
    Ich habe allerdings auch AS/400-Systeme gesehen wo QUTCOFFSET immer 00:00 war und die Systemzeit halt immer umgestellt wird. Da bring so ein Timezone-Timestamp nun auch nichts.

    Hat SQL denn schon die Funktionen "LocalTime" oder UTCTime realisiert?
    Kann die AS/400 ähm IBM i inzwischen mehrere Zeitzonen (ohne Aufwand) auf derselben Maschine?
    Ich habe dies für Kunden schon realisieren müssen.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  4. #16
    Registriert seit
    Oct 2019
    Beiträge
    16
    Stimmt schon, wenn man beim Erstellen der Timestamp das UTC Offset mitspeichert ist das relativ einfach zu handhaben. Wenn man aber nur die Timestamp hat und im Nachhinein das UTC Offset wissen will, braucht man z.B. mktime. Leider ist das mit dem vernünftigen Design nicht unbedingt immer gegeben...

  5. #17
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    "Wenn man aber nur die Timestamp hat und im Nachhinein das UTC Offset wissen will, braucht man z.B. mktime"???
    Erfindest du das Offset dann?

    C-Funktionen wie mktime, localtime usw. setzen eine Umgebungsvariable TZ (Timezone) voraus, sonst funktionieren sie nicht. Der Systemwert QUTCOFFSET wird allerdings nicht verwendet.
    Außerdem:

    The C library function time_t mktime(struct tm *timeptr) converts the structure pointed to by timeptr into a time_t value according to the local time zone.
    M.a.W.:
    - jeder beliebige Zeitstempel muss bereits als UTC vorliegen.
    - Die Umrechnung erfolgt mit der aktuellen TZ, also nicht der vergangenen TZ

    Per Locale-Einstellung (Userprofíl) kann die Variabel TZ jobspezifisch gesetzt werden.
    Hast du das mal geprüft?

    Wie gesagt, ich musst das mal realisieren, da unterschiedliche Zeitzonen (alleine schon wegen GB) benötigt wurden.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  6. #18
    Registriert seit
    Oct 2019
    Beiträge
    16
    "Erfindest du das Offset dann?"
    Nö, mktime versucht es zu ermitteln. Wie schon gesagt, das funktioniert gut außer bei der Stunde Überlappung beim Übergang von Sommer- zu Winterzeit, die defaulted immer zum Offset der Winterzeit.

    A negative value for tm_isdst causes mktime() to attempt to determine whether DST is in effect for the specified time.

    Code:
      // 1 Stunde UTC-Offset für Winterzeit
      dsply timestampToISO8601(z'2021-01-01-14.00.00');
    
      // 2 Stunde UTC-Offset für Sommerzeit
      dsply timestampToISO8601(z'2021-08-01-14.00.00');
    Das sollte auf einem System in der CET folgendes ausgeben:
    Code:
    DSPLY 2021-01-01T13:00:00Z
    DSPLY 2021-08-01T12:00:00Z
    Es wird also jeweils das richtige UTC Offset ermittelt.

  7. #19
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Dann verstehe ich die Beschreibung allerdings nicht:
    https://www.ibm.com/docs/en/i/7.4?to...ert-local-time
    Laut Beschreibung wird die aktuelle Zeitzone zur Errechnung der UTC verwendet.

    "For this conversion, mktime() checks the current locale setting for local time zone and daylight saving time (DST). If these values are not set in the current locale, mktime() gets the local time zone and daylight saving time settings from the current job."

    D.h. Wenn ich einen Timestamp, also Localtime, aus der Zeitzone USA nehme wird er mit der aktuellen Zeitzone meines Jobs/Systems in UTC umgerechnet.
    Ebenso entscheidet die aktuelle Einstellung von DST ob nun Sommer/Winterzeit berücksichtigt wird.
    Dies ist i.Ü. auch meine Erfahrung.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. Format von PF ändern
    By _MG_ in forum NEWSboard Programmierung
    Antworten: 8
    Letzter Beitrag: 21-04-17, 14:09
  2. RDI - /End-Exec im festen Format
    By homue in forum NEWSboard Programmierung
    Antworten: 8
    Letzter Beitrag: 25-07-16, 15:27
  3. Feldgruppen im free-Format
    By kretzsch in forum NEWSboard Programmierung
    Antworten: 3
    Letzter Beitrag: 14-08-14, 13:02
  4. XML-Ausgabe in Cobol im Format UTF-8
    By Günter in forum NEWSboard Programmierung
    Antworten: 10
    Letzter Beitrag: 26-06-14, 15:10
  5. JDBC Datum Format EUR
    By camouflage in forum NEWSboard Java
    Antworten: 1
    Letzter Beitrag: 02-12-13, 16:58

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •