Zeitzonen – das ultimative “Spass”-Problem, das jeder Entwickler liebt zu hassen. Wenn du denkst, dass die Sommerzeit nervig ist, versuch mal, Zeiten über mehrere Kontinente hinweg zu synchronisieren – vor allem in einem Geschäftsfeld, in dem absolute Genauigkeit gefragt ist.

Das Problem: Wie spät ist es wirklich? Link zu Überschrift

Stell dir vor: Du leitest ein Projekt von der Schweiz aus, aber deine Reinigungsteams arbeiten in Japan. Jemand meldet ein Problem um 14:00 Uhr Ortszeit, doch dein System zeigt 03:00 Uhr an. Hä? Haben die mitten in der Nacht angerufen? Nein – dein System war einfach zu “hilfsbereit” und hat alles in deine lokale Zeitzone umgerechnet. Super für Google Kalender, aber katastrophal für die Echtzeit-Problemerfassung.

Die technische Lösung Link zu Überschrift

Um Chaos zu vermeiden, brauchen wir ein System, das sicherstellt, dass eine Reinigung um 08:00 Uhr in Japan tatsächlich als 08:00 Uhr in Japan angezeigt wird – auch wenn du sie aus der Schweiz betrachtest. Die Lösung? Immer mit UTC im Hintergrund arbeiten und nur bei der Anzeige in die lokale Zeitzone umwandeln.

So läuft es ab:

  1. Der Browser erfasst Datum und Uhrzeit.
  2. .toISOString() wandelt es in UTC um.
  3. Das Backend speichert und verarbeitet alles als UTC.
  4. Beim Lesen wird die Zeit zurück in die lokale Zeitzone konvertiert.

Klingt einfach? (Ist es nicht – aber dafür gibt es Code.)

Umgang mit Datum und Zeit (Beispiel: 25.10.2021 10:00:00) Link zu Überschrift

Backend-Logik Link zu Überschrift

  • ZonedDateTime.now() gibt immer UTC zurück. Keine Ausnahmen. Niemals.
  • Falls eine Umrechnung nötig ist, benutze TimeZoneHelper. Andernfalls gibt’s später Tränen.
  • Alles, was in die Datenbank kommt, muss UTC sein.
  • Den richtigen Wochentag ermitteln? Nicht einfach .getDayOfWeek() nutzen – das gibt dir den UTC-Wochentag, nicht den lokalen. Stattdessen: TimeZoneHelper.getDayOfWeekInTheZone() verwenden.

Frontend – wo es noch komplizierter wird Link zu Überschrift

Das Frontend muss mitspielen, denn JavaScript liebt es, lokale Zeit und UTC zu vermischen. Daher setzen wir es immer auf die Zeitzone der wirtschaftlichen Einheit:

  • Standardzeitzone korrekt im State setzen (moment.tz.setDefault(value.data.timeZone)).
  • Für die Anzeige DateTimeConverter nutzen.
  • Falls du Zeiten vergleichst, moment.js nutzen – aber sparsam! Zu viele Umwandlungen killen die Performance.

Performance-Vergleich: Link zu Überschrift

Umwandlung Zeit
new Date() 2-4 ms
moment() 40-70 ms

Kurz gesagt: moment.js nur dort einsetzen, wo es wirklich nötig ist.

Umgang mit reinen Uhrzeiten (Beispiel: 17:00:00) Link zu Überschrift

Nur die Uhrzeit (ohne Datum) in UTC speichern? Vergiss es. Die Sommerzeit wird dir alles kaputtmachen.

Beispiel (wir wollen die Zeit 17:00:00 speichern):

  • Datenbank speichert 15:00:00 für MEZ Sommerzeit (+2).
  • Im Sommer (+2) ist UTC 17:00 → Korrekt ✅
  • Im Winter (+1) ist UTC 16:00 → Falsch ❌

Die Lösung Link zu Überschrift

Wir speichern immer die lokale Zeit in der Datenbank und wandeln nur bei Bedarf um.

  • Datenbank speichert 17:00:00 in MEZ.
  • Im Sommer (+2) ist UTC 15:00 → Korrekt ✅
  • Im Winter (+1) ist UTC 16:00 → Korrekt ✅

Uhrzeit zu einem Datum setzen Link zu Überschrift

Falls du eine bestimmte Uhrzeit in einem Date-Objekt setzen musst: Vorsicht! Erst Mitternacht in der lokalen Zeitzone ermitteln, dann Stunden und Minuten hinzufügen, um eine Verschiebung zu vermeiden. Verwende den Helper: TimeZoneHelper.setLocalTimeOnZonedDate(ZonedDateTime date, DateTimeZone zone, LocalTime time)

Das stellt sicher, dass 17:00:00 auch wirklich 17:00:00 bleibt und nicht durch Zeitzonenverschiebungen zu 16:00:00 oder 18:00:00 wird.

Vergleiche Link zu Überschrift

  • Datum ignorieren und nur die Uhrzeit vergleichen (now.isAfter(compareTime)).
  • Falls ein Datum verglichen werden muss: Erst in die richtige Zeitzone konvertieren, dann die lokale Zeit hinzufügen.

Zeitvergleiche über Zeitzonen hinweg Link zu Überschrift

Zeitvergleiche sind tricky, weil du immer zuerst die richtige Zeitzone setzen musst. Besser so:

LocalTime now = TimeZoneHelper.setToZone(now, economicEntity.getDateTimeZone()).toLocalTime();
now.isAfter(compareTime);

Falls du eine bestimmte Tageszeit vergleichen musst, immer erst die richtige Zeitzone setzen, bevor du die lokale Zeit addierst – sonst vergleichst du Äpfel mit UTC-Orangen.

Frontend-Vereinfachung Link zu Überschrift

Im Frontend halten wir das Zeitmanagement so einfach wie möglich. Keine Umwandlungen – Uhrzeiten werden als Strings behandelt und ans Backend gesendet. Die Umrechnung macht dann das Backend, weil Zeit-Handling im Frontend ohnehin schon kompliziert genug ist.

Fazit Link zu Überschrift

Zeitzonen sind fies, aber mit der richtigen Strategie lassen sie sich unter Kontrolle halten. Die goldene Regel? UTC speichern, lokale Zeit anzeigen und jede Umrechnung doppelt prüfen – es sei denn, du möchtest um 03:00 Uhr nachts debuggen.

TimeZoneHelper