Zeit sieht aus wie eine Zahl und verhält sich wie ein Regelwerk. In verteilten Systemen mit Servern, Clients, Datenbanken und Schnittstellen treffen mehrere Zeitverständnisse aufeinander, und die daraus entstehenden Fehler sind besonders unangenehm: Sie treten selten auf, meist nachts, und sie verfälschen still Auswertungen, statt einen Fehler zu werfen.
Drei Arten von Zeitangaben, die nicht vermischt werden dürfen
Der häufigste Konstruktionsfehler ist, alles in denselben Datentyp zu schreiben. Fachlich sind es aber drei verschiedene Dinge:
- Zeitpunkt: Etwas ist passiert. Eindeutig, unveränderlich, gehört in UTC gespeichert.
- Lokale Zeitangabe: Ein Termin, der lokal gelten soll. Braucht zusätzlich die gemeinte Zeitzone als Name, nicht als Offset.
- Kalenderdatum ohne Uhrzeit: Ein Geburtstag oder Stichtag. Wird durch eine Zeitzonenumrechnung nur kaputtgemacht.
Wer diese drei unterscheidet, hat den größten Teil der späteren Probleme bereits vermieden. Wer alles als Zeitstempel mit Zone behandelt, verschiebt Geburtstage um einen Tag, sobald ein Nutzer in einer anderen Region arbeitet.
UTC speichern, lokal anzeigen — und die Ausnahme
Für protokollierte Ereignisse gilt eine einfache Regel: intern in UTC rechnen und speichern, ausschließlich an der Oberfläche in die Zeitzone des Betrachters umrechnen. Das macht Sortierung, Differenzbildung und Zusammenführung über Systemgrenzen hinweg eindeutig.
Die Ausnahme betrifft die Zukunft. Ein wöchentlicher Termin um neun Uhr Ortszeit ist keine feste UTC-Zeit, denn zwischen heute und dem Termin kann sich die Zonenregel ändern — Länder haben ihre Regeln in der Vergangenheit mehrfach angepasst. Deshalb gehört bei zukünftigen Terminen die lokale Zeit plus der Zeitzonenname gespeichert und erst zur Ausführung nach UTC aufgelöst.
Der Offset ist eine Momentaufnahme, der Zonenname ist die Regel. Wer bei zukünftigen Terminen nur den Offset ablegt, hat einen Termin gespeichert, der nach der nächsten Umstellung eine Stunde daneben liegt — ohne dass irgendwo ein Fehler auftaucht.
Die zwei Stunden im Jahr, die alles brechen
Bei der Umstellung auf Sommerzeit fehlt eine Stunde vollständig, bei der Rückstellung existiert eine Stunde zweimal. Beides erzeugt reale Fehler: Ein nächtlicher Verarbeitungslauf, der um halb drei startet, läuft an einem Tag im Jahr gar nicht und an einem anderen doppelt. Genau deshalb gehören solche Läufe entweder außerhalb der kritischen Zeitfenster geplant oder gegen Mehrfachausführung abgesichert.
Die zweite Baustelle sind Auswertungen. Ein Tag hat an diesen Wochenenden 23 oder 25 Stunden. Kennzahlen wie Umsatz pro Tag oder Anzahl je Stunde weisen dort eine Abweichung aus, die keine ist. Wer Vergleiche über solche Zeiträume zieht, sollte den Effekt kennen, bevor er ihn als Geschäftsentwicklung interpretiert.
Wiederkehrende Termine gehören als Regel gespeichert
Serientermine werden oft als Liste einzelner Zeitpunkte materialisiert. Das ist bequem und wird bei jeder Änderung teuer: Ändert sich die Serie, müssen alle Einträge korrigiert werden, und Ausnahmen gehen verloren. Robuster ist, die Regel zu speichern und Einzeltermine daraus abzuleiten:
- Startzeitpunkt als lokale Zeit plus Zonenname.
- Wiederholungsregel in einem standardisierten Format statt in eigener Logik.
- Ausnahmen und verschobene Einzeltermine getrennt von der Regel.
- Ein Vorlauffenster, in dem konkrete Termine für die Ausführung vorberechnet werden.
Damit bleibt ein Serientermin auch dann korrekt, wenn sich Zonenregeln oder die Serie selbst ändern.
Grenzen von Auswertungszeiträumen
Der zweithäufigste Zeitfehler betrifft nicht den einzelnen Zeitstempel, sondern die Grenzen eines Zeitraums. Ein Tagesbericht braucht eine definierte Zone, sonst verschiebt sich der Tagesanfang je nach Serverstandort. Besonders tückisch sind Abfragen, die ein Datum mit einem Zeitstempel vergleichen: Ohne saubere Bereichsgrenzen fällt der letzte oder erste Datensatz des Tages heraus oder wird doppelt gezählt. Robuster ist, Zeiträume immer als halboffenes Intervall zu formulieren — von einschließlich Startzeitpunkt bis ausschließlich Endzeitpunkt. Das funktioniert unabhängig von der Genauigkeit der gespeicherten Zeitstempel und bleibt auch dann korrekt, wenn später Millisekunden hinzukommen.
Uhren, Reihenfolgen und Protokolle
In verteilten Systemen kommt hinzu, dass Uhren auseinanderlaufen. Zwei Server können Ereignisse mit Zeitstempeln versehen, deren Reihenfolge nicht der tatsächlichen entspricht. Wer Reihenfolge braucht, sollte sie nicht allein aus Zeitstempeln ableiten, sondern aus einer fortlaufenden Nummer oder einer serverseitig vergebenen Sequenz.
Für die Nachvollziehbarkeit gilt derselbe Grundsatz wie bei Änderungsprotokollen: Ein Zeitstempel ohne eindeutige Zonenangabe ist im Zweifel wertlos, weil er sich später nicht mehr verlässlich einordnen lässt — ein Punkt, der auch bei Audit-Logs über die Belastbarkeit der Aufzeichnung entscheidet.
Zeit ist damit kein Formatierungsthema, sondern eine Architekturentscheidung. Sie wird einmal getroffen und wirkt in jeder Auswertung, jedem Termin und jedem Protokoll nach.