Zeitumstellung: Zeitstempel in ERP-Schnittstellen prüfen

Die Umstellung ist kein Sprung der Zeit, sondern ein Sprung der Beschriftung. Die koordinierte Weltzeit läuft ohne Unterbrechung weiter; was sich ändert, ist der Abstand, mit dem die lokale Uhr auf sie zeigt. Die gesetzliche Zeit in Deutschland ist die mitteleuropäische Zeit, bestimmt durch die koordinierte Weltzeit unter Hinzufügung einer Stunde (Bundesministerium der Justiz); während der Sommerzeit sind es zwei Stunden (Bundesministerium der Justiz). Im Oktober fällt dieser Abstand von zwei auf eine Stunde, im März steigt er zurück.

Daraus entstehen zwei Sonderfälle, die in einer Schnittstelle unterschiedlich wehtun. Im Oktober gehört eine Ortszeit zu zwei verschiedenen Zeitpunkten: 2:30 Uhr gibt es zweimal, einmal mit dem Offset +02:00 und einmal mit +01:00. Im März gehört eine Ortszeit zu gar keinem Zeitpunkt, weil die Stundenzählung von 2 Uhr auf 3 Uhr vorgestellt wird (Bundesministerium der Justiz) – 2:30 Uhr existiert an diesem Tag nicht. Ein Feld vom Typ Datum-und-Uhrzeit ohne Zonenangabe kann den ersten Fall nicht auflösen und den zweiten nicht zurückweisen. Es nimmt beide Werte an und reicht sie weiter, wie sie hereingekommen sind.

Die belastbare Aufteilung ist alt, und sie hält: Ein Zeitpunkt wird in koordinierter Weltzeit gespeichert, in Weltzeit übertragen und erst in der Anzeige in die Zone des Betrachters umgerechnet. Der Internetstandard RFC 3339 begründet das mit der Sache selbst: Weil die Regeln für die Sommerzeit verwickelt sind und sich durch örtliches Recht zu unvorhersehbaren Zeitpunkten ändern können, empfiehlt er für echte Zusammenarbeit über Systemgrenzen die koordinierte Weltzeit (RFC Editor). Das ist keine Stilfrage, sondern die Zusicherung, dass ein Wert auch dann noch denselben Zeitpunkt bezeichnet, wenn ein anderes Land seine Regel ändert.

Diese Regel hat eine Ausnahme, die man kennen muss, sonst baut man sie falsch: Wandzeiten sind keine Zeitpunkte. Ein Abholtermin am Lager um 8 Uhr, eine Angebotsfrist zum Monatsende und ein Liefertag hängen am Kalender, nicht an einer Sekunde auf der Weltzeitachse. Wer solche Werte in Weltzeit umrechnet und als Zeitpunkt speichert, verschiebt sie bei der nächsten Umstellung um eine Stunde. Sie gehören als Datum, als Uhrzeit oder als Uhrzeit mit Zonennamen abgelegt – und der Zonenname gehört dazu, sonst weiß der zweite Standort nicht, wessen 8 Uhr gemeint sind.

Die meisten Anbindungen holen Änderungen nicht als Ereignisstrom, sondern als Abfrage: Gib mir alles, was sich seit dem Zeitpunkt X geändert hat. Der Zeitpunkt X stammt aus dem letzten Lauf, das Feld im ERP heißt sinngemäß geändert-am, und solange beide dieselbe Zeitachse benutzen, geht das gut. In der Umstellungsnacht geht es auf zwei Weisen schief, und beide Wege bleiben still – kein Abbruch, kein Eintrag im Fehlerprotokoll, nur ein anderer Datenbestand als erwartet.

Im Oktober läuft die Ortszeit eine Stunde doppelt. Ein Lauf, der seinen Hochwasserstand in Ortszeit führt, liest die Stunde 2A, merkt sich 2:59 Uhr und liest in der Stunde 2B alles noch einmal, was zwischen 2:00 und 2:59 Uhr geschrieben wurde. Im Frühjahr fehlt die Stunde: Wer in der Anwendung eine Sicherheitsspanne von einer Stunde abzieht, um Uhrenversatz auszugleichen, fragt nach einem Zeitpunkt, den es an diesem Tag nicht gibt, und bekommt je nach Bibliothek eine stille Verschiebung oder einen Abbruch. Doppelt gelesene Datensätze sind dabei der harmlosere Fall, solange die Verarbeitung idempotent ist; übersprungene Datensätze fallen erst auf, wenn ein Kunde nach seinem Auftrag fragt.

Welcher Offset an welchem Datum gilt, steht in keiner Formel, sondern in einer Tabelle. Betriebssysteme, Laufzeitumgebungen und Datenbanken lesen diese Tabelle aus der Zeitzonendatenbank, die bei der Internet Assigned Numbers Authority gepflegt wird. Sie ändert sich, sobald ein Land seine Regel ändert – und das geschieht häufiger, als es die Ruhe in Mitteleuropa vermuten lässt. Zwischen Januar 2025 und Juli 2026 sind sechs Datenstände erschienen (IANA).

Ein Beispiel aus dem laufenden Jahr zeigt die Vorlaufzeit: Der Datenstand 2026c vom 8. Juli 2026 kündigt den Wechsel Marokkos auf einen dauerhaften Offset von +00:00 zum 20. September 2026 an (IANA). Wer Termine oder Fristen mit Partnern dort abstimmt, braucht diesen Datenstand in jedem beteiligten System: im Anwendungsserver, in der Datenbank und in der Middleware. Ein System, das mit einem älteren Stand rechnet, liefert eine plausible, aber verschobene Ortszeit; nichts daran sieht nach einem Fehler aus. Deshalb gehört der Zonendatenstand in die Auslieferung wie eine Programmbibliothek – und in die Testumgebung, bevor er in den Betrieb geht.

Die Frage, ob die halbjährliche Umstellung bleibt, wird seit Jahren diskutiert. Die Europäische Kommission führte dazu im Sommer 2018 eine öffentliche Konsultation durch. Obwohl der Konsultationszeitraum kürzer war als der übliche Zeitraum von zwölf Wochen, gingen rund 4,6 Millionen Antworten ein, 99 Prozent davon von Bürgerinnen und Bürgern (Europäische Kommission). 84 Prozent aller Befragten sprachen sich für die Abschaffung der zweimal jährlich stattfindenden Zeitumstellung aus, 16 Prozent wollen sie beibehalten (Europäische Kommission). Eine offene Konsultation befragt allerdings keine gezogene Stichprobe, sondern jene, die von sich aus antworten – die Zahlen beschreiben die Teilnehmer, nicht die Bevölkerung.

Für die Praxis in einer Schnittstelle folgt daraus eine schlichte Konsequenz: Maßgeblich ist die Regel, nach der die Uhren heute gestellt werden, und die steht in der Sommerzeitverordnung und in der Richtlinie 2000/84/EG. Ändert sich eine Zeitregel, erreicht die Änderung die Systeme über einen neuen Datenstand der Zeitzonendatenbank und nicht über eine Nachricht im Posteingang. Eine Anbindung, die Zeitpunkte in Weltzeit führt und die Umrechnung an einer einzigen Stelle vornimmt, übersteht das mit einem Aktualisierungsschritt; eine Anbindung, die Ortszeiten durch fünf Systeme reicht, braucht dafür ein Projekt. Es ist derselbe Hebel wie bei der Auflösung von Datenkonflikten im beidseitigen Abgleich: Wer eine führende Quelle bestimmt, muss später weniger schlichten.