-
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.
-
Hier hat Birgitta schon einmal was zu den Zeitzohnen gesagt:
#3
-
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.
-
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...
-
"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.
-
"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.
-
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.
Similar Threads
-
By _MG_ in forum NEWSboard Programmierung
Antworten: 8
Letzter Beitrag: 21-04-17, 14:09
-
By homue in forum NEWSboard Programmierung
Antworten: 8
Letzter Beitrag: 25-07-16, 15:27
-
By kretzsch in forum NEWSboard Programmierung
Antworten: 3
Letzter Beitrag: 14-08-14, 13:02
-
By Günter in forum NEWSboard Programmierung
Antworten: 10
Letzter Beitrag: 26-06-14, 15:10
-
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
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks