Zeit scheint einfach — bis man versucht, Software zu schreiben, die sie korrekt verarbeitet. Ein Termin um „15 Uhr" bedeutet in Tokio, London und New York etwas Verschiedenes. Die Sommerzeit verschiebt die Uhren vor oder zurück — aber nicht überall, und nicht an denselben Daten. Ein Zeitstempel, der in Ihrer lokalen Umgebung korrekt aussieht, funktioniert in der Produktion nicht, weil der Server in einer anderen Zeitzone steht.
Zeitzonen gehören zu den zuverlässig verwirrendsten Themen in der Softwareentwicklung. Dieser Artikel erklärt, wie sie funktionieren, woher die Komplexität kommt und wie Sie die häufigsten Fehler vermeiden.
Warum Zeitzonen existieren
Die Erde dreht sich in 24 Stunden um 360 Grad, was bedeutet, dass die Sonne je nach Längengrad zu unterschiedlichen Zeitpunkten ihren höchsten Stand erreicht. Vor dem 19. Jahrhundert stellte jede Stadt ihre Uhren nach der lokalen Sonnenzeit — Mittag war, wenn die Sonne im Zenit stand. Das funktionierte gut, bis Eisenbahnen entfernte Städte verbanden und ein Fahrplan eine einheitliche Uhr brauchte.
1884 trafen sich Delegierte aus 25 Nationen auf der Internationalen Meridiankonferenz in Washington, D.C. und einigten sich darauf, die Welt in 24 Standard-Zeitzonen aufzuteilen, jeweils versetzt zum Nullmeridian (0 Grad Länge), der durch Greenwich, England, verläuft.
In der Praxis folgen Zeitzonengrenzen politischen Grenzen, nicht sauberen Längengraden. China erstreckt sich über fünf geografische Zeitzonen, verwendet aber eine einzige offizielle Zeit (UTC+8). Indien verwendet UTC+5:30 — einen halbstündigen Versatz. Nepal verwendet UTC+5:45. Die reale Zeitzonenkarte ist unübersichtlich.
UTC vs. GMT
GMT (Greenwich Mean Time) ist die mittlere Sonnenzeit am Royal Observatory in Greenwich. Es war über ein Jahrhundert lang die Zeitreferenz der Welt.
UTC (Coordinated Universal Time) ersetzte GMT 1972 als internationalen Standard. UTC basiert auf Atomuhren statt auf astronomischer Beobachtung, was es weitaus präziser macht. Für die meisten praktischen Zwecke zeigen UTC und GMT die gleiche Zeit an, aber UTC ist die korrekte technische Referenz.
Warum „UTC" und nicht „CUT"? Die Abkürzung ist ein Kompromiss zwischen dem englischen „Coordinated Universal Time" (CUT) und dem französischen „Temps Universel Coordonné" (TUC). Keine Seite bekam ihr bevorzugtes Kürzel, daher wurde UTC als sprachneutrale Alternative gewählt.
Sommerzeit: organisiertes Chaos
Etwa 70 Länder beachten die Sommerzeit (DST), indem sie die Uhren im Frühjahr eine Stunde vor und im Herbst zurückstellen. Die Absicht ist, die Wachstunden an das Tageslicht anzupassen. Das Ergebnis ist eine halbjährliche Quelle von Fehlern.
Wesentliche Komplikationen:
- Nicht universal. Die meisten Länder in Afrika, Asien und Südamerika beachten keine Sommerzeit. In den USA verzichten Arizona und Hawaii darauf.
- Unterschiedliche Daten. Die EU stellt am letzten Sonntag im März und Oktober um. Die USA stellen am zweiten Sonntag im März und ersten Sonntag im November um. Sie sind mehrere Wochen im Jahr nicht synchron.
- Mehrdeutige Zeiten. Wenn die Uhren zurückgestellt werden, kommt die Stunde von 1:00 bis 2:00 Uhr zweimal vor. Ein Zeitstempel „1:30 Uhr" an diesem Tag ist mehrdeutig.
- Übersprungene Zeiten. Wenn die Uhren vorgestellt werden, existiert die Stunde von 2:00 bis 3:00 Uhr nicht. Ein Termin um 2:30 Uhr an diesem Tag findet nie statt.
- Politische Änderungen. Regierungen können (und tun dies) DST-Regeln kurzfristig ändern. Russland führte 2011 permanente Sommerzeit ein und wechselte 2014 zu permanenter Normalzeit. Marokko hat die DST-Regeln mehrfach geändert.
ISO 8601: Das universelle Datumsformat
Um Mehrdeutigkeiten zu vermeiden, definiert der internationale Standard ISO 8601 ein klares Datums- und Zeitformat:
2026-03-29T14:30:00Z
2026-03-29T14:30:00+02:00
2026-03-29T14:30:00-05:00
- Das
Ttrennt Datum von Zeit. Zbedeutet UTC (die „Zulu"-Zeitzone in militärischer Terminologie).+02:00oder-05:00ist der UTC-Offset.
Dieses Format ist eindeutig, als Klartext sortierbar und von Datums-Parsing-Bibliotheken universell verstanden. Im Zweifel verwenden Sie ISO 8601.
Unix-Timestamps
Ein Unix-Timestamp (auch Epoch Time oder POSIX Time genannt) ist die Anzahl der Sekunden, die seit dem 1. Januar 1970, 00:00:00 UTC vergangen sind — ein Moment, der als Unix-Epoche bekannt ist.
| Menschenlesbar | Unix-Timestamp |
|---|---|
| 1970-01-01 00:00:00 UTC | 0 |
| 2000-01-01 00:00:00 UTC | 946684800 |
| 2026-03-29 12:00:00 UTC | 1774987200 |
Unix-Timestamps haben keine Zeitzone — sie sind immer in UTC. Das macht sie ideal zum Speichern und Vergleichen von Zeiten in Software. Die Umrechnung in eine lokale Zeitzone erfolgt erst in der Anzeigeschicht.
Das Jahr-2038-Problem: Systeme, die Unix-Timestamps als 32-Bit-Ganzzahl mit Vorzeichen speichern, laufen am 19. Januar 2038 um 03:14:07 UTC über. Der Maximalwert (2.147.483.647) springt auf eine negative Zahl um, die als Dezember 1901 interpretiert wird. Die meisten modernen Systeme verwenden 64-Bit-Ganzzahlen, die erst in 292 Milliarden Jahren überlaufen.
Die IANA-Zeitzonendatenbank
Software benötigt nicht nur UTC-Offsets — sie muss die vollständige Geschichte und zukünftige Regeln für jede Region kennen, einschließlich DST-Übergängen, politischen Änderungen und historischen Anomalien. Diese Informationen sind in der IANA Time Zone Database (auch Olson-Datenbank oder tzdata genannt) gespeichert.
Sie verwendet Bezeichner wie America/New_York, Europe/Paris, Asia/Tokyo. Jeder Eintrag enthält die vollständige Geschichte der UTC-Offsets und DST-Regeln für diesen Standort.
Deshalb sollten Sie niemals eine Zeitzone als festen Offset wie „+02:00" speichern. Ein Offset sagt Ihnen die aktuelle Differenz zu UTC, aber nichts über DST-Regeln. Europe/Paris ist im Winter UTC+1 und im Sommer UTC+2. Der IANA-Bezeichner erfasst beides.
Häufige Fehler in Software
- Lokale Zeit ohne Zeitzone speichern. Ein Wert wie
2026-03-29 14:30:00ist bedeutungslos, ohne zu wissen, auf welche Zeitzone er sich bezieht. Speichern Sie immer UTC oder fügen Sie den Offset bei. - Annehmen, UTC-Offset gleich Zeitzone. UTC+2 im März kann UTC+3 im Juli sein (wenn die Region Sommerzeit beachtet). Speichern Sie den IANA-Bezeichner, nicht den Offset.
- DST-Übergänge bei der Terminplanung ignorieren. Ein täglicher Job um 2:30 Uhr wird einmal im Jahr übersprungen und einmal doppelt ausgeführt, wenn Sie DST nicht berücksichtigen.
- Annehmen, Tage haben 24 Stunden. An DST-Übergangstagen hat ein Tag 23 oder 25 Stunden. „Morgen um die gleiche Zeit" durch Addition von 86.400 Sekunden zu berechnen, weicht um eine Stunde ab.
- JavaScript
Datenaiv verwenden.new Date("2026-03-29")wird in einigen Engines als UTC und in anderen als lokale Zeit geparst. Geben Sie die Zeitzone immer explizit an.
Best Practices für Entwickler
- Zeiten in UTC speichern. Konvertieren Sie in die lokale Zeitzone des Nutzers erst in der Präsentationsschicht.
- IANA-Zeitzonen-Bezeichner verwenden (
America/New_York), nicht feste Offsets (-05:00). - ISO 8601 für die Serialisierung verwenden. Es ist eindeutig und universell parsebar.
- Eine ausgereifte Datumsbibliothek verwenden. In JavaScript nutzen Sie
Intl.DateTimeFormatoder eine Bibliothek wiedate-fns-tz. In Pythonzoneinfo(3.9+) oderpytz. In Javajava.time.ZonedDateTime. tzdataaktuell halten. Regierungen ändern DST-Regeln. Ihr Betriebssystem und Ihre Sprachlaufzeitumgebung benötigen aktuelle Zeitzonendaten.- Mit mehreren Zeitzonen testen. Gehen Sie nicht davon aus, dass Ihr Server und Ihre Nutzer dieselbe Zeitzone haben.
Weiterführende Informationen
Zeit ist trügerisch komplex, aber die Regeln sind gut dokumentiert und die Werkzeuge ausgereift. Der Schlüssel liegt darin, die Komplexität zu respektieren, statt sie zu ignorieren.
- Cron-Ausdrücke entmystifiziert — Aufgaben über Zeitzonen hinweg planen
- Hash Generator und Regex Tester — weitere Entwickler-Tools auf ToolK