Timestamp

[mk]

Hallo zusammen,

aus einer Anwendung bekommen wir solche Timstampfelder
Hat jemand eine Idee ob diese Feldinhalte mit SQL übernommen werden können ?


"2022-04-08T12:09:49+0200"


Gruß
Michael

[Fuerchau]

Dies ist der neue "Timestamp with Timezone".
D.h, der 1. Teil ist die UTC-Zeit "2022-04-08T12:09:49", der 2. Teil ist die Zeitzone "+0200", also derzeit MESZ.
Dafür gibts dann in SQL "TIMESTAMP(n) with timezone" sowie die Umrechnung localtime(), die den Timstamp dann umrechnet.
Das "T" ist dann durch ein Leerzeichen zu ersetzen.

Im Ilerpg kannst du aber die mitgelieferte Zeitzone auch selber auf den Timestamp draufrechnen.

[mk]

Dies ist der neue "Timestamp with Timezone".
D.h, der 1. Teil ist die UTC-Zeit "2022-04-08T12:09:49", der 2. Teil ist die Zeitzone "+0200", also derzeit MESZ.
Dafür gibts dann in SQL "TIMESTAMP(n) with timezone" sowie die Umrechnung localtime(), die den Timstamp dann umrechnet.
Das "T" ist dann durch ein Leerzeichen zu ersetzen.

Im Ilerpg kannst du aber die mitgelieferte Zeitzone auch selber auf den Timestamp draufrechnen.



SQL ist der Hit

:-)


Gruß
Michael

[dschroeder]

Dies ist der neue "Timestamp with Timezone".
D.h, der 1. Teil ist die UTC-Zeit "2022-04-08T12:09:49", der 2. Teil ist die Zeitzone "+0200", also derzeit MESZ.
Dafür gibts dann in SQL "TIMESTAMP(n) with timezone" sowie die Umrechnung localtime(), die den Timstamp dann umrechnet.
Das "T" ist dann durch ein Leerzeichen zu ersetzen.


Ich habe gerade ein ähnliches Problem. Ich muss Daten, die als RFC 3339 Timestamp kommen, in unseren IBM i timestamp konvertieren bzw. unseren Timestamp in das RFC Format bringen.

Gibt es da eine SQL Syntax "TIMESTAMP(n) with timezone" ? Bei mir klappt das nicht. Oder habe ich die Antwort falsch verstanden?

So etwas geht:
values timestamp('2022-09-07 17:16:12.123');

Folgendes geht nicht:
values timestamp('2022-09-07T17:16:12.123Z');
Gibt es dafür eine SQL-Interpretierungsfunktion?

Dieter

[Fuerchau]

Jo: timestamp(replace(trim(char(var), 'Z'), 'T', ' '))

[B.Hauser]

1. Timestamp(n) with timezone gibt es NICHT in Db2 for i! (nur auf den anderen Db2s)
2. Die Konvertierung geht auch einfacher:

Values Timestamp(Translate('2022-09-07T17:16:12.123Z', ' ', 'TZ'));

[dschroeder]

Herzlichen Dank an euch beide.

Das Z steht ja für Zulu Time (also die Greenwich Zeit). In der Regel werden wir die Ortszeit aus Deutschland bekommen. Die hätte dann anstatt des Z den Zeitoffset hinten dran: '2022-09-07T17:16:12.123+02:00'

Es gibt da dafür nichts "Fertiges" in SQL? Ich muss also selber aktiv werden und mit timestamp und timezone rechnen?

Es geht mir auch um die Ausgabe (als JSON). Unsere Kollegen hätten gerne einen Timestamp der obigen Form (also mit Zeit-Offset). Den kann ich natürlich über eine Funktion "basteln". Aber ich hatte gehofft, dass IBM da inzwischen etwas bereitgestellt hat. Angeblich ist RFC 3339 ja der weltweite Standard (wegen Internet).

[B.Hauser]

Nein, was fertiges gibt es auf der IBM i nicht (zumindest nicht im Standard-Umfang der Db2 for i).
Vielleicht findest Du etwas Open Source.
... ansonsten selberbasteln.

[Fuerchau]

Zumal die Zeitzone aktuell nur per Systemwert auslesbar ist.
Der Timestamp auf der IBM i ist immer localtime!
Um also die UTC-Zeit zu bekommen musst du eine external Function schreiben, die den aktuellen Offset aus dem Systemwert ausliest und die UTC dann ausrechnet.
Ggf. kannnst du so eine eigene Cast-Funktion schreiben, die das Ergebnis als CHAR-Feld zurückgibt.

Ich verstele den Hype um den Timestamp with Timezone sowieso nicht.
Wenn ich in der DB grundsätzlich UTC speichere, kann ich ja jederzeit den Timestamp mit "+00:00" ausgeben. Die Anzeige der Localtime ist ja sowieso immer Sache des Clients, da dessen Zeitzone für die Darstellung gilt. Es interessiert mich halt nicht, wie die Zeitzone mal war als die Zeit eingestellt wurde.

Ich habe mal für Infor-XPPS das Problem "mehrere Zeitzonen auf der IBM i" lösen müssen, was aktuell nur mit den C-UnixAPI's und den Locale-Einstellungen je Job funktioniert.
SQL und ILERPG interessieren sich dafür allerdings nicht.

Ach ja: Und das Problem der doppelten/fehlenden Zeiten für Differenzrechnung und Sortierungen bei der Zeitumstellung gibts bei Verwendung von UTC nicht.

[dschroeder]

OK,
vielen Dank. Ihr habt mir, wie immer, sehr weiter geholfen!