Datum OHNE Uhrzeit Zeitzonen-übergreifend

TomH

Mitglied
Hallo zusammen,
ich bin jetzt nach so vielen Jahren auf ein (vermeintlich simples) Problem gestoßen, wofür ich aber keine Lösung finde.

In unserer Anwendung gibt es Datumswerte mit und ohne Uhrzeit (teilweise fest definiert, teilweise vom Anwender konfigurierbar, welche Datumswerte eine Uhrzeit haben können und welche nicht). Bei denen, die keine Uhrzeit haben, wird diese auf 00:00 Uhr gesetzt und auch so in der DB gespeichert.

Die Anwendung wird von Kunden nicht nur unter deutscher Zeitzone betrieben, aber bisher war es wohl anscheinend so, dass es immer Zeitzonen waren, die zeitlich vor der deutschen liegen (also Richtung Westen), da fällt das Problem nicht auf.
Ein Anwender in Lissabon (Portugal ist eine Stunde zurück, die arbeiten auf einem Server mit deutscher Zeitzone, auf die auch deutsche Anwender mit deutscher Zeitzone zugreifen) bekommt jetzt natürlich alle Datumswerte ohne Uhrzeit (00:00 Uhr) falsch angezeigt, nämlich einen Tag davor mit (impliziter, nicht sichtbaren Uhrzeit 23:00), da durch die Zeitzonen-Konvertierung eine Stunde abgezogen wird. Das ist natürlich sehr ungünstig und hier soll eigentlich keine Konvertierung stattfinden.
Bsp:
In DB und bei Anwendern mit deutscher Zeitzone steht "07.07.2022" (nicht sichtbare Uhrzeit 00:00), in Portugal steht "06.07.2022" (nicht sichtbare Uhrzeit 23:00)

Was mich am meisten irritiert.... dieses Problem ist ja nicht neu, das müssen doch viele haben. Wie kann ich das lösen, dass hier keine Konvertierung stattfindet? Oder gibt es eine Möglichkeit wieder zu dem ursprünglichen Datum zurückzukommen, dass man es zumindest korrekt anzeigt auf der Oberfläche. Wir verwenden für Datumswerte durchgängig java.sql.Timestamp. Habe experimentiert mit java.time.LocalDate, aber das bringt mich auch nicht weiter. Das was ich aus dem Server auf den Client bekomme ist nun mal ein Timestamp und das hat nun mal schon die falschen Daten.

Ein möglicher Ansatz wäre evtl. die Uhrzeit nicht auf 00:00 Uhr zu setzen, sondern auf 12:00 Uhr, dann müsste zwischen Client-Zeitzone und Server-Zeitzone schon mehr als 12h Unterschied sein, damit man wieder in den Fehler läuft, aber das ist ja trotzdem keine 100%-Lösung.

Falls einer von Euch eine praktikablere Lösung hätte, wäre ich für einen Post hier sehr dankbar.

VG
Tom
 
Ich hätte vielleicht nicht 00:00: Uhr für Datum ohne Zeit benutzt, sondern 12:00 Uhr

auch die Zeitzone mit gespeichert und ausgewertet.
 
Das Problem hier ist, wie du ja richtig erkannt hast, dass "2022-01-01 00:00:00" ein bestimmter Zeitpunkt im Zeitstrahl ist (siehe java.time.Instant). Ein reines Datum "2022-01-01" hingegen ist dies eigentlich nicht, weil die Angabe einer Uhrzeit dafuer notwendig ist (wenn auch implizit immer "00:00:00" angenommen wird). Jetzt habt ihr genau dieses Problem, ihr habt nicht ein "absolutes" Datum, sondern den "relativen" Zeitpunkt "2022-01-01 00:00:00" zusammen mit einer Zeitzone in der Datenbank gespeichert (oder der Server konvertiert diese auf seine Zeitzone, was viel gruseliger waere).

Ich sehe da jetzt gerade nur zwei moegliche Loesungen: Die erste waere, ihr fuehrt eine eigene Spalte fuer "einfache" Daten ein, dann koennt ihr, idealerweise, einmal java.time.LocalDate und einmal java.time.OffsetDateTime aus der Datenbank holen.

Oder, zweite Moeglichkeit, ihr holt euch immer OffsetDateTime aus der Datenbank, prueft dann ob die Uhrzeit Mitternacht ist und reduziert dieses dann auf LocalDate ohne die Zeitzone zu beruecksichtigen.
 
Mich würde ein mal interessieren, was genau Du machst. Welche Klassen verwendest Du? Welche Datenbank?

Es gibt gewisse Anpassungen. Oracle Datenbank speichert ein Date in UTC, d.h. der Client bekommt das ohne Timezone in der lokalen Zeit.

Man kann da also im Detail durchaus drauf schauen um das dann zu lösen. Evtl. hilft dieser SO Thread etwas:

Die neue API mit Instant wäre ggf. eine mögliche Lösung denke ich.
 
Hallo zusammen,
vielen Dank für die vielen Anregungen.

Bevor ich euch noch weiter löchere, schaue ich mir erst mal die "neue" Time-API noch genauer an. Die habe ich bisher noch nie verwendet.

VG
Tom
 

Zurück
Oben