Ein Meeting wird eine Stunde zu spät angezeigt, eine Frist rückt auf den Vortag oder eine wiederkehrende Aufgabe findet nicht mehr zur erwarteten Uhrzeit statt. Solche Fehler haben oft dieselbe Ursache: Unterschiedliche Zeitangaben werden gleich behandelt. Eine durchdachte Zeitzonenverwaltung in Anwendungen muss festlegen, was ein Datum bedeutet, welche Informationen gespeichert werden und wie mehrdeutige Fälle aufzulösen sind.
Die Lösung besteht nicht einfach darin, alles in UTC zu speichern oder stets die Gerätezeit anzuzeigen. Entscheidend ist, ob ein Eintrag ein einmaliges Ereignis, ein Kalenderdatum oder eine Regel beschreibt, die sich nach der Ortszeit eines bestimmten Standorts wiederholen soll. Die folgenden Schritte helfen dabei, diese Verhaltensweisen festzulegen und zu prüfen, bevor sie sich auf Nutzer oder Abläufe auswirken.
Zeitpunkte, Kalenderdaten und Ortszeiten unterscheiden
Ein Zeitpunkt ist ein eindeutiger Moment auf der Zeitachse. Er ist für alle derselbe, auch wenn verschiedene Personen ihn mit unterschiedlichen Uhrzeiten sehen. Der Eintrag einer Transaktion oder der Zeitpunkt, zu dem eine Benachrichtigung versendet wurde, ist in der Regel ein Zeitpunkt. Solche Werte lassen sich als auf UTC normalisierte Zeitstempel speichern und für die Anzeige umrechnen.
Ein Kalenderdatum ist ein Datum wie der 15. Mai, ohne Uhrzeit oder implizite Zeitzone. Ein Geburtsdatum, ein Feiertag oder der letzte Tag zur Abgabe eines Formulars kann diese Bedeutung haben. Eine Umrechnung in UTC kann den Kalendertag verschieben. Daher sollte ein solches Datum nicht als Zeitpunkt modelliert werden, wenn keine konkrete Uhrzeit vorgegeben ist.
Eine Ortszeit bezeichnet eine Uhrzeit an einem bestimmten Ort, etwa 9 Uhr in Madrid. Für sich allein legt sie keinen Zeitpunkt fest: Dafür braucht es auch das Datum und die Zeitzone, und bei bestimmten Zeitumstellungen kann die Angabe weiterhin mehrdeutig sein. Klären Sie im Produktmodell zunächst, was Nutzer beim Lesen eines Werts verstehen sollen, bevor Sie den passenden Speichertyp festlegen.
Was gespeichert werden sollte: UTC, IANA-Zeitzone und Originalwert
Speichern Sie bei einem bereits bestätigten Einzelereignis den Zeitpunkt in UTC. Wenn die gewählte Zeitzone wichtig ist, um die Entscheidung zu erklären oder die ursprüngliche Nutzererfahrung nachvollziehen zu können, bewahren Sie zusätzlich die IANA-Zeitzone auf, zum Beispiel Europe/Berlin, und bei Bedarf auch die ursprüngliche lokale Eingabe. Eine IANA-Zeitzone enthält regionale Regeln, die sich im Lauf der Zeit ändern können. Sie ist nicht mit einem festen Offset wie UTC+01:00 gleichzusetzen.
Ein Offset gibt die Differenz zu UTC zu einem bestimmten Zeitpunkt an. Für sich allein enthält er weder die Regeln zur saisonalen Zeitumstellung noch künftige gesetzliche Änderungen. Ein Datum mit Offset in einer API kann daher ausreichen, um einen Zeitpunkt zu bestimmen, aber nicht immer, um die Absicht „um 9 Uhr in Berlin“ zu bewahren. Übertragen Sie in diesem Fall den Zeitpunkt und die Zeitzonenkennung getrennt.
Verwenden Sie für Kalenderdaten ein Feld oder einen Datentyp, der ausschließlich Jahr, Monat und Tag abbildet. Speichern Sie für eine wiederkehrende Regel – etwa ein Meeting jeden Montag um 9 Uhr an einem Standort – die Ortszeit, die IANA-Zeitzone und die Wiederholungsregel. Wandeln Sie die Regel nicht in eine dauerhaft festgelegte Folge von UTC-Uhrzeiten um: Ändert sich der lokale Offset, könnte das Meeting für die Teilnehmenden nicht mehr um 9 Uhr stattfinden.
Legen Sie außerdem Genauigkeit und Validierung fest. Klären Sie, ob Sekunden oder Sekundenbruchteile zulässig sind, welche Formate die einzelnen APIs akzeptieren und wie Werte ohne Zeitzone behandelt werden. Ein Wert ohne Offset und ohne Zeitzone kann in verschiedenen Systemen unterschiedlich interpretiert werden. Weisen Sie ihn zurück oder definieren Sie eine ausdrückliche Regel, statt stillschweigend die Zeitzone des Servers anzunehmen.
Uhrzeiten passend zu Kontext und Absicht anzeigen
Bei einem bereits vergangenen Ereignis ist es oft hilfreich, Datum und Uhrzeit in der Zeitzone des Nutzers anzuzeigen. Bezieht sich ein Geschäftsvorgang auf einen bestimmten Standort, kann die dortige Uhrzeit verständlicher sein. Bei Meetings über mehrere Regionen hinweg sollten Sie erwägen, beide Zeitzonen oder zusätzlich den Standort anzugeben. Entscheidend ist die praktische Frage: Wann muss die Person handeln, und welche Uhrzeit gilt dabei?
Vermeiden Sie unklare Bezeichnungen wie „Ortszeit“, wenn nicht ersichtlich ist, wessen Ortszeit gemeint ist. Geben Sie bei wichtigen Bestätigungen und Hinweisen die Zeitzone oder den Standort mit ausreichend Kontext an. Eine Mitteilung zu einem Termin kann beispielsweise die vereinbarte Uhrzeit am Standort nennen und für Empfänger in einer anderen Region zusätzlich die entsprechende Uhrzeit dort anzeigen. Prüfen Sie, dass die Umrechnung für den richtigen Zeitpunkt erfolgt und nicht auf einem festen Offset aus einer veralteten Konfiguration beruht.
Nutzerpräferenzen und Geschäftsregeln stimmen nicht immer überein. Ein Nutzer möchte möglicherweise alle Aktivitäten in seiner Zeitzone sehen, während für eine rechtliche Frist das von der Organisation festgelegte Datum und die zugehörige Zeitzone gelten. Machen Sie diese Priorität in der Oberfläche und in der Logik deutlich: Eine Änderung der Anzeigeeinstellungen sollte die offizielle Frist nicht unbemerkt verändern.
Fristen, Termine und saisonale Zeitumstellungen korrekt behandeln
Klären Sie vor der Planung einer Frist, ob sie zu einem bestimmten Zeitpunkt oder am Ende eines Kalendertags abläuft. „Bis zum 15. Mai“ kann bedeuten, dass der gesamte Tag in einer bestimmten Zeitzone zählt – nicht, dass die Frist um Mitternacht UTC zu Beginn dieses Tages endet. Dokumentieren Sie die für die Frist maßgebliche Zeitzone, ob die Grenze ein- oder ausgeschlossen ist und wie die Oberfläche das darstellt.
Bei saisonalen Zeitumstellungen gibt es zwei getrennt zu behandelnde Fälle. Beim Vorstellen der Uhr kann eine bestimmte Uhrzeit nicht existieren; beim Zurückstellen kann eine andere Uhrzeit zweimal vorkommen. Bei einer Eingabe in einer nicht existierenden Uhrzeit sollte das Produkt die Eingabe mit einer Erklärung ablehnen oder eine vereinbarte Regel anwenden, etwa auf die nächste gültige Uhrzeit verschieben. Bei einer doppelt vorkommenden Uhrzeit sollte es nachfragen, welcher der beiden Zeitpunkte gemeint ist, oder eine eindeutige Regel auswählen und kommunizieren.
Bei wiederkehrenden Aufgaben sollten Sie die Regel in Ortszeit speichern und jedes nächste Vorkommen anhand der Regeln der Zeitzone berechnen. Legen Sie fest, was bei einem Wechsel der Zeitzone geschieht, wenn ein Ausführungstag auf einen arbeitsfreien Tag fällt oder wenn die Uhrzeit nicht existiert. Eine Aufgabe, die in einem festgelegten realen Zeitabstand ausgeführt werden soll – beispielsweise alle 24 Stunden ab einem Startzeitpunkt –, unterscheidet sich von einer Aufgabe, die an jedem Kalendertag zur gleichen Uhrzeit stattfinden soll.
Abweichungen zwischen APIs, Datenbanken und Systemen vermeiden
Eine Integration kann eine ansonsten korrekte Richtlinie zunichtemachen, wenn einzelne Komponenten Felder unterschiedlich interpretieren. Vereinbaren Sie deshalb Verträge, die Format, Zeitzone, Genauigkeit und Bedeutung festlegen. Ein Feld namens created_at sollte einen Zeitpunkt darstellen; ein Feld wie due_date könnte ein Kalenderdatum bezeichnen. Der Name allein reicht jedoch nicht: Die Dokumentation muss die Bedeutung festhalten.
Prüfen Sie, dass Präsentationsschichten den ursprünglichen Wert nicht verändern und externe Systeme die IANA-Zeitzone beim Import eines Termins nicht verwerfen. Berücksichtigen Sie auch Warteschlangen, Exporte, Berichte und Protokolle: Ein Bericht, der nach UTC-Kalendertagen gruppiert, kann andere Summen ausweisen als ein Bericht, der nach den lokalen Tagen eines Standorts gruppiert. Keine der Gruppierungen ist automatisch falsch, aber sie muss zur jeweiligen geschäftlichen Fragestellung passen.
Zeitzonenregeln können sich durch behördliche Entscheidungen ändern. Verwenden Sie für künftige Berechnungen die zum Berechnungszeitpunkt gültigen Regeln und berücksichtigen Sie, dass eine Aktualisierung die nächsten Umrechnungen beeinflussen kann. Bewahren Sie für Prüfzwecke genügend Informationen auf, um nachvollziehen zu können, welchen Wert der Nutzer erhalten hat und welche Zeitzone angewendet wurde. Gehen Sie nicht davon aus, dass ein Zeitstempel allein die ursprüngliche Absicht hinter einem Termin dokumentiert.
Tests und Checkliste für eine gemeinsame Richtlinie
Tests sollten mehr als gewöhnliche Umrechnungen abdecken. Beziehen Sie Daten rund um Zeitumstellungen, Zeitzonen mit und ohne saisonale Wechsel, Nutzer und Unternehmen in unterschiedlichen Regionen, Kalenderdaten sowie historische Werte ein. Prüfen Sie sowohl den gespeicherten Wert als auch die Anzeige auf Bildschirmen, in Nachrichten, Berichten und integrierten Systemen.
- Ordnen Sie den Datentyp ein: Zeitpunkt, Kalenderdatum, Ortszeit mit Zeitzone oder wiederkehrende Regel.
- Legen Sie die maßgebliche Quelle fest: Zeitzone des Nutzers, Standort, Rechtsgebiet oder Einstellung des Ereignisses.
- Definieren Sie eindeutige Regeln: mehrdeutige Eingaben, nicht existierende Uhrzeiten, Fristgrenzen und Werte ohne Zeitzone.
- Dokumentieren Sie den Vertrag: Formate, Genauigkeit, Felder und erwartete Umrechnungen in jeder API.
- Testen Sie Sonderfälle: Zeitumstellung, Tageswechsel, unterschiedliche Zeitzonen, Regelaktualisierungen und Wiederholungsversuche.
- Prüfen Sie die Kommunikation: Stellen Sie sicher, dass klar ist, wann gehandelt werden muss und welche Zeitzone für die Frist gilt.
Eine gute Richtlinie für Zeitangaben macht aus impliziten Annahmen sichtbare Regeln. Speichern Sie Zeitpunkte als Zeitpunkte, Kalenderdaten als Daten und lokale Wiederholungen zusammen mit ihrer Zeitzone. Prüfen Sie anschließend, ob Produkt, Betrieb und Integrationen dieselbe Bedeutung zugrunde legen. So lassen sich unerwartete Verschiebungen vermeiden und Abweichungen leichter erklären.