Questions & Answers

[matthiasforberg]

Hallo,

ich habe ein bis zwei Fragen bzgl. Datumsberechnungen.

Bislang gab es im Projekt die Standard-Datumseingabe über CMS_INPUT_DATE mit mode="datetime", also Eingabe von Datum und Uhrzeit zusammen. Jetzt wollten die Redakteure aber eine Trennung haben, damit die Uhrzeit immer auf einen Standardwert vorbelegt werden kann und nur im Bedarfsfall geändert wird. Also haben wir jetzt zwei DATE Komponenten, eine mit mode="date", die andere mit mode="time".

Da glücklicherweise für beide Varianten das jeweils fehlende Datum mit 0 gespeichert wird, habe ich mir gedacht, ich kann Datum und Uhrzeit einfach addieren und bekomme wieder das komplette Datum, so wie vorher.

Folgende Konstellation habe ich jetzt:

altes Datum:

• stDateTime (mode="datetime")

neues Datum:

• stDate (mode="date")
• stTime (mode="time")

Meine Addition sieht so aus:

$CMS_SET(setDateTimeNew, stDate.plus(stTime.milliseconds))$

Im Ergebnis bekomme ich immer eine Stunde weniger als bei stDateTime.

Soweit so gut, das steht ja eigentlich auch in der ODFS. Ich versteht bloß nicht, warum EINE Stunde? Server und Client stehen in derselben Zeitzone MESZ und das sind 2 Stunden Unterschied zu UTC. Wie kommt aber die eine Stunde zustande? Ich will die wieder drauf addieren, aber nicht stumpf als Konstante, sondern ich will verstehen, wie genau diese Differenz zustande kommt und die wenn möglich abfragen und addieren.

Und hier noch die zweite Frage:

wenn ich den obigen SET-Aufruf mit timeInMillis statt milliseconds mache, also so...

$CMS_SET(setNewDateTime, stDate.plus(stTime.timeInMillis))$

...dann bekomme ich einen Nullpointer. Durch die Vorbelegung ist stTime aber nie leer, sondern hat immer einen Wert. Ich dachte immer der Rückgabewert beider Methoden wäre identisch, aber das ist wohl nicht so? Worin besteht der Unterschied?

Grüße

Matthias

[Peter_Jodeleit]

Im Modus "time" liefert die Komponente das Delta in Millisekunden zu 1.1.1970 0:00, und das Zeitzonen-Unabhängig (siehe dazu auch in der Dokumentation). Leider ist der Umgang mit Datum und Zeit in Java ziemlich umständlich, wenn man nicht java.time von Java 8 verwenden kann.

[matthiasforberg]

Ja genau, das habe ich ja auch schon gelesen, aber wenn ich "Zeitzonen-unabhängig" lese, würde ich erwarten, dass die Zeit in UTC gespeichert wird (steht ja auch in der Doku). Wir sind UTC+1 und haben die Sommerzeit, also nochmal ne Stunde dazu. Eins von beiden wird offenbar bei der Ausgabe unterschlagen (oder doch wieder dazu addiert?), so dass am Ende nur 1 Stunde Differenz entsteht, statt der erwarteten entweder 0 (lokal) oder 2 Stunden (UTC).

Mit getTimeZone bekomme ich für alle Variablen dieselbe Ausgabe zurück, nämlich die lokale Zeit. Dann bleibt mir wohl erstmal nichts anderes als eine Stunde als Konstante drauf zu addieren. Es bleibt aber ein mulmiges Gefühl dabei...

[matthiasforberg · Accepted solution]

Zur Info, ich habe eine Lösung gefunden (aber besonders elegant finde ich die immer noch nicht).

Folgender Vergleich des "Null-Datums" hat mich auf die Idee gebracht. Ich erzeuge mir ein Datum, von dem ich erwarte, dass es in Millisekunden ausgegeben Null sein muss:

$CMS_VALUE(class("java.util.Date").new(70,0,1,0,0,0).format("yyyy-MM-dd HH:mm:ss"))$
$CMS_VALUE(class("java.util.Date").new(70,0,1,0,0,0).milliseconds)$

Ausgabe:

1970-01-01 00:00:00
-3600000

Obwohl das formatierte Datum richtig mit 0:00 Uhr ausgegeben wird, haben die Millisekunden einen Offset von -1 Stunde.

Lösung:

Ich setze ganau diesen Offset als Konstante (in den Projekteinstellungen):

$CMS_SET(psMillisecondsOffset, -(class("java.util.Date").new(70,0,1,0,0,0).milliseconds))$

Und beim Addieren von Datum und Uhrzeiten gebe ich den noch dazu:

$CMS_SET(setDateTimeNew, stDate.plus(stTime.milliseconds + psMillisecondsOffset))$

Jetzt weiß ich zwar immer noch nicht, warum dieser Offset entsteht, aber immerhin korrigiere ich ihn mit sich selbst. Sollte er also doch mal 0 sein, passt es hoffentlich auch.

(Im Internet habe ich übrigens Java-Forumseinträge von genau diesem Problem gefunden. Die haben aber keine Lösung gefunden, deswegen verweise ich hier nicht darauf.)

Viele Grüße

Matthias