Zweimal jährlich erleben Millionen Europäer das gleiche Ritual: Die Uhren werden gestellt, zurück auf Normalzeit im Oktober, vor auf Sommerzeit im März. Was für viele nur ein Griff zum Wecker ist, bedeutet für IT-Systeme, Unternehmen und internationale Teams jedes Mal eine kleine Herausforderung. Besonders jetzt, wo am letzten Oktoberwochenende die Zeitumstellung bevorsteht, lohnt sich ein Blick hinter die Kulissen der Zeitzonen und auf das, was bei der Zeitumstellung wirklich passiert.
Warum ist das Thema relevant?
Ob Terminplanung, Server-Logs, Geschäftsprozesse oder internationale Kommunikation, fehlerhafte Zeitberechnungen führen zu Missverständnissen, Ausfällen oder gar Datenverlusten. Unternehmen, die global agieren oder automatisierte Prozesse laufen lassen, müssen die Eigenheiten von Zeitzonen und Zeitumstellung kennen und technisch sauber abbilden. In diesem Beitrag zeigen wir, wie das zuverlässig gelingt und warum wir als Software-Dienstleister hier souverän Unterstützung bieten können.
In der Nacht auf den letzten Sonntag im Oktober wird die Uhr von 3:00 auf 2:00 Uhr zurückgestellt: Die Sommerzeit endet, die Normalzeit (Mitteleuropäische Zeit, MEZ/CET) beginnt. In der Praxis bedeutet das eine Stunde mehr Schlaf, aber auch eine Stunde, die im Zeitverlauf doppelt existiert.
Technische Folge:
Zwischen 2:00 Uhr und 3:00 Uhr gibt es in dieser Nacht jeden Zeitpunkt zweimal. Systemprozesse, die auf exakte Zeitangaben angewiesen sind (z. B. Buchungen, Log-Einträge, automatisierte Aktionen), können dadurch durcheinandergeraten.
Beispiel:
Ein Job ist für 2:30 Uhr geplant: Führt das System ihn zweimal aus? Oder gar nicht? Genau diese Fälle sorgen jedes Jahr wieder für Supportanfragen.
Der umgekehrte Fall tritt im Frühjahr ein, wenn die Uhr im März von 2:00 Uhr direkt auf 3:00 Uhr vorgestellt wird. Die Zeit zwischen 2:00 Uhr und 3:00 Uhr existiert dann schlicht nicht. Versucht ein System, in dieser «verschwundenen Stunde» eine Aufgabe zu terminieren, wird diese Aufgabe niemals ausgeführt.
Automatisierte Prozesse laufen entweder doppelt (bei Rückstellung) oder gar nicht (beim Vorsprung im März).
Nicht überall auf der Welt gelten die gleichen Regeln. Während die EU die Uhr am letzten Sonntag im März und Oktober umstellt, gelten in den USA etwa andere Termine, ebenso in Australien und Neuseeland. Selbst Zeit und Tag der Umstellung können je nach Land variieren.
Darüber hinaus gibt es zahlreiche Länder, die mittlerweile gar keine Zeitumstellung mehr durchführen. In Kanada beispielsweise verzichten einige Provinzen wie Saskatchewan seit Jahren auf die Umstellung, während andere sie beibehalten. Auch viele asiatische und afrikanische Länder kennen keine Sommerzeit.
Auf der Südhalbkugel kehrt sich das Prinzip sogar um. Während in Europa im März die Uhr vorgestellt wird, beginnt dort der Herbst und die Uhr wird zurückgestellt. Das bedeutet, dass zu einem bestimmten Zeitpunkt auf der Welt gleichzeitig Sommer- und Winterzeit herrschen kann.
Hinzu kommt: Die Regeln zur Zeitumstellung sind nicht in Stein gemeisselt. Sie wurden in der Vergangenheit immer wieder geändert und können auch in Zukunft angepasst oder ganz abgeschafft werden.
Eine Zeitzone ist ein definierter Bereich auf der Erde, in dem die gleiche lokale Zeit gilt. Die Grundlage bildet die Koordinierte Weltzeit (UTC). Zeitzonen werden als Abweichung (Offset) zu UTC angegeben, zum Beispiel UTC+1 für Mitteleuropa.
Was viele nicht wissen: Es gibt mehr als 24 Zeitzonen-Offsets. Nicht alle Abweichungen sind ganze Stunden, und die Spannweite ist grösser als 24 Stunden.
- Ungewöhnliche Offsets: Indien (UTC+5:30), Nepal (UTC+5:45) oder die Chathaminseln (UTC+12:45 bzw. UTC+13:45 in deren Sommerzeit)
- Maximaler Zeitunterschied: 26 Stunden zwischen UTC−12 (z. B. Baker Island, USA) und UTC+14 (z. B. Line Islands, Kiribati). Das führt dazu, dass es an einem Ort bereits Montag ist, während es an einem anderen noch Samstag ist
Mit der Umstellung auf Sommerzeit verschiebt sich die lokale Zeit im Sommer um eine Stunde nach vorn (UTC+2 statt UTC+1 in Mitteleuropa).
Der Offset allein sagt aber nicht, ob an diesem Ort gerade Sommerzeit gilt. UTC+02:00 kann in Europa MESZ (CEST, Sommerzeit) sein, ist in Südafrika (z. B. Africa/Johannesburg) jedoch ganzjährig Standardzeit (SAST, keine Sommerzeit).
Konsequenz: Mit Offsets allein sind korrekte Datums- und Zeitberechnungen über Regionen, DST-Umstellungen und historische Änderungen hinweg praktisch unmöglich.
World_Time_Zones_Map, licensed under PDM 1.0
Zeitzonenregeln sind keine Konstanten. Regierungen ändern Offsets oder Sommerzeitregelungen mitunter kurzfristig, zudem gibt es historisch viele Abweichungen. Software muss diese Änderungen korrekt abbilden, sonst drohen doppelte Jobs, verpasste Ausführungen oder fehlerhafte Auswertungen.
Die IANA Time Zone Database ist der De‑facto‑Standard, um Zeitregeln konsistent zu modellieren. Sie definiert stabile Bezeichner im Format Region/Stadt (z. B. Europe/Berlin, America/New_York) und liefert die dafür gültigen Übergänge und Offsets.
Was die IANA‑Daten bereitstellen:
- Eindeutige Zone‑IDs: Kanonische Kennungen plus Aliase für Abwärtskompatibilität
- Regeln und Übergänge: Beginn/Ende der Sommerzeit, Offset‑Wechsel und deren genaue Zeiträume
- Historie: Vergangene Änderungen, damit Zeitstempel rückwirkend korrekt interpretiert werden können
- Aktualität: Regelmässige Releases bei politischen Anpassungen
Zeitpunkte immer in UTC speichern
Die Speicherung von Zeitstempeln sollte grundsätzlich in UTC erfolgen. UTC ist eine zeitzonenneutrale Darstellung und unterliegt keinen saisonalen Änderungen. Dies verhindert Mehrdeutigkeiten und erleichtert Berechnungen über Zeitzonengrenzen hinweg. Erst bei der Anzeige für Nutzer erfolgt die Konvertierung in die jeweilige lokale Zeitzone.
IANA Zeitzonen Informationen mitführen
Neben dem UTC-Zeitstempel sollte auch die IANA-Zeitzone gespeichert werden, in der ein Ereignis stattfindet. Dies ermöglicht es, bei zukünftigen Regeländerungen die lokale Zeit korrekt zu rekonstruieren. Ein Zeitstempel ohne Zeitzoneninformation kann bei nachträglichen Änderungen der Sommerzeitregelungen falsch interpretiert werden.
Zeitberechnungen immer in der Zielzeitzone durchführen
Berechnungen wie «füge drei Tage hinzu» sollten nicht direkt auf UTC-Zeitstempeln durchgeführt werden, wenn das Ergebnis in einer bestimmten Zeitzone gelten soll. Stattdessen sollte der Zeitpunkt in die Zielzeitzone konvertiert und dort die Berechnung durchgeführt werden. Dies stellt sicher, dass Sommerzeitübergänge korrekt berücksichtigt werden.
Testen kritischer Prozesse rund um die Zeitumstellung
Automatisierte Tests sollten explizit die Zeitumstellungszeitpunkte abdecken. Unit-Tests können mit simulierten Systemzeiten arbeiten, um das Verhalten bei der Zeitumstellung zu prüfen. Dabei sollten beide Szenarien getestet werden: die fehlende Stunde im Frühjahr und die doppelte Stunde im Herbst. Manuelle Tests in Staging-Umgebungen vor den tatsächlichen Umstellungsterminen helfen, potenzielle Probleme frühzeitig zu identifizieren.