AppDevPack: Falsche Zeitzone in Kalendereintrag

[pantelis.botsas]

Domino: R11
Notes: R11.0.1-FP3
AppDevPack: domino-db-1.9.0 + node-iam-cient-2.0.0

Hallo zusammen,

ich habe eine nodeJS Anwendung entwickelt, welche die oben genannten Pakete nutzt.
In dieser Anwendung gibt es eine Routine, welche Kalendereinträge in den Kalender des angemeldeten Benutzers erstellt.
Hierbei nutze ich die von HCL vorgegebene Dokumentation zur Festlegung der Feldwerte in Dokumenten (https://doc.cwpcollaboration.com/appdevpack/docs/en/domino-db-schema.html).

Für einen Kalendereintrag wird natürlich ein Zeitraum für den Beginn (StartDate, StartDateTime) und das Ende (EndDate, EndDateTime) einer Veranstaltung, Besprechung, usw. festgelegt. Zusätzlich werden die Eigenheiten beim Anlegen von wiederkehrenden Terminen berücksichtigt. Alle diese Datum/Zeit-Werte übergebe ich als UTC Date, UTC DateTime bzw. UTC Time. Wobei UTC Time irrelevant ist, da dieser Wert gleich ist mit der von mir vorgegebenen Uhrzeit.
Dazu nutze ich das node-Paket luxon, welches die Umrechnung in UTC vornimmt.

In meiner Entwicklungsumgebung kann ich die Kalendereinträge speichern und diese werden mit exakt der Uhrzeit im Kalender angezeigt, welche ich zuvor beim Anlegen der Dokumente mittels UTC Date/DateTime vorgegeben habe.

In der Testumgebung und in der Produktivumgebung jedoch, laufen die Uhrzeiten davon. Die Kalendereinträge stehen während der Sommerzeit zwei Stunden in der Zukunft und in der Normalzeit eine Stunde in der Zukunft.

Auf allen Servern (Entwicklung, Test, Produktiv) ist als Zeitzone "UTC+1 Amsterdam, Berlin" eingestellt.

Lasse ich mir auf der Konsole die Einzelschritte beim Erstellen des Dokumentes anzeigen, stehen exakt die gleichen Werte drin, mit denen in der Entwicklungsumgebung problemlos den Kalendereintrag mit den gewünschten Zeiten erstellt wird (in dem Beispiel hier: 2021-09-16T06:00:00.00Z).

Ich habe inzwischen Einiges ausprobiert. Auslesen der Zeitzone auf dem Server, explizites Zuweisen der Zeitzone des Servers beim Berechnen der Zeiten für den Kalendereintrag. Doch leider hilft hier nichts weiter. Kalendereinträge, die um 8 Uhr beginnen sollen, landen auf 10 Uhr.

Den einzigen Unterschied, den ich in den Dokumenten nach dem Speichern sehen kann ist:

1) In der Entwicklungsumgebung steht für die Startzeit 6AM GMT
-> was dann zum richtigen Ergebnis 8AM UTC+1 (+daylight saving time) bzw. 8AM UTC+1 (normal time), je nach Datum

2) In der Test- und Produktivumgebung steht für die Startzeit aber 8AM GMT bzw. 7AM GMT (ab dem 31. Oktober), obwohl ich dem Feld explizit mitteile, dass dort 2021-09-16T06:00:00.00Z stehen soll.

Hat irgendjemand von euch dieses Phänomen schon mal gehabt?

Über jeden Hinweis bin ich dankbar.

[pantelis.botsas]

Hallo nochmal zusammen,

ich habe das Problem durch Umwege gelöst und wollte euch über die Erkenntnisse auf dem Laufenden halten.

Auf die richtige Fährte bin ich jedoch erst gekommen, nachdem ich mir sowohl im Browser (Frontend) als auch auf dem Server (Backend) jeweils die aktuelle Zeitzone ausgegeben habe.

In der Entwicklungsumgebung stimmte die Zeitzone (Europe/Berlin) des Frontends mit der Zeitzone (Europe/Berlin) des Backends überein.
Deshalb hat es hier keine Probleme gegeben, da die Umwandlung von 8 Uhr vormittags (Zeitzone Europe/Berlin) in UTC genau das gewünschte Ergebnis 6AM GMT+2 liefert.

In der Test- und Produktivumgebung jedoch, war trotz der exakt gleichen Einstellungen für Region und Zeitzone aber etwas anders.
Zum einen liefen beide Layer (Frontend und Backend) nicht direkt auf dem Server, sondern waren jeweils in einem Docker-Container gekapselt.
Und hier fängt es an, interessant zu werden.

Im Docker-Container sieht es wohl so aus, dass dieser grundsätzlich auf UTC-Zeit vor sich hin wurschtelt. Unabhängig davon, welche Regionaleinstellungen über das darunter liegende Betriebssystem mitgegeben werden.
Gibt man sich in diesem Kontext die Zeitzone des Servers aus, erhält man immer UTC.
Und bei näherer Betrachtung ist dieses Verhalten auch mehr als richtig so.

Um das Problem nun so zu lösen, dass ich nicht auch noch anfangen muss, irgendwelche Regionaltabellen durchzuhecheln, hat folgender Ansatz zum Ziel geführt.

Bei der Übergabe der Daten für den Kalendereintrag aus dem Frontend, hole ich mir die Zeitzone des Systems, mit dem der Benutzer derzeit aktiv arbeitet.
Glücklicherweise hilft mir dabei das in der zuvor gestellten Frage genannte node-Paket "luxon", genau das herauszufinden.

const dtZone = DateTime.local().zoneName

Diese Information übergebe ich mit dem Speicherauftrag aus dem Frontend mit ins Backend (weiterer Inhalt im POST request).

Im Backend ziehe ich diese Information dann aus dem POST-Request heraus.

Beim Berechnen der Zeiten für einen Kalendereintrag, der am ersten Tag beispielweise um 12 Uhr beginnen soll (Feld StartTime), gehe ich nunmehr so vor:

DateTime.fromISO(myISODate).setZone(dtZone).set({ hour: 12 }).toUTC().toISOTime({ includeOffset: false, suppressMilliseconds: true }) }

Mit der Methode fromISO übergebe ich das aus dem Frontend übermittelte Datum (im ISO Format). Dabei entsteht ein neues Luxon DateTime-Object.
Im nächsten Schritt setze ich explizit die Zeitzone, die ich aus dem Frontend mitgeteilt habe.
Erst DANACH setze ich die gewünschte Uhrzeit.
Im Anschluss wandle ich das nun vorhanden DateTime-Object in UTC-Notation um, und formatiere schlussendlich die ermittelte Uhrzeit ins vom AppDev-Pack geforderte ISO-Format - ohne Millisekunden  .

Bei einer Kombination von Datum und Zeit (z. B. für das Feld StartDateTime) sieht das dann so aus:

DateTime.fromISO(myISODate).setZone(dtZone).set({ hour: 12 }).toUTC().toISO({ suppressMilliseconds: true }) }

Ich habe diesen Ansatz nun an allen Stellen implementiert, in denen Zeitvorgaben gemacht werden. Und mit diesem Ansatz stehen die Kalendereinträge genau so im Kalender, wie sie der Benutzer auch erwartet.

Hoffentlich hilft das dem Einen oder der Anderen hier weiter, damit keine unnötigen Runden beim Entwickeln entstehen.

Lieben Gruß,
Pantelis