Unix-Zeitstempel und Zeitzonen: Woher die Verwirrung kommt

Jede Entwicklerin versteht Zeit, bis der zweite Sonntag im März kommt.

Was ein Unix-Zeitstempel ist

Eine Zählung von Sekunden seit dem 1. Januar 1970 um 00:00:00 UTC, ohne Schaltsekunden. Eine Zahl, keine Zeitzone daran, denn sie wird immer gegen UTC gemessen. Zu jedem Zeitpunkt sollten sich alle Maschinen der Welt darauf einigen.

1761000000 ist der 20. Oktober 2025 um 22:40 UTC. In Tokio liest sich das als 21. Oktober, 07:40. In New York als 20. Oktober, 18:40. Ein Moment, drei Arten ihn zu sagen, und nur die Zahl ist der Moment. Alles andere ist Darstellung.

Unser Unix-Zeitstempel-Konverter rechnet in beide Richtungen, in jeder Zone.

Stellen zählen

• 10 Stellen, 1761000000, Sekunden. Die klassische Form.
• 13 Stellen, 1761000000000, Millisekunden. Was Date.now() liefert.
• 16 Stellen, Mikrosekunden. Verbreitet in Datenbanken und Tracing-Systemen.

Geben Sie Millisekunden an etwas, das Sekunden erwartet, landen Sie um das Jahr 57.774 herum, was immerhin offensichtlich falsch ist.

Zonen sind Regeln, Offsets sind Zahlen

Ein Offset ist eine Verschiebung: +05:30, -08:00. Eine Zone ist eine Regel, die sagt, wann welcher Offset gilt.

+05:30              ein Offset, für immer fest
Asia/Kolkata        eine Zone, die immer +05:30 ist
Europe/London       eine Zone, +00:00 im Winter und +01:00 im Sommer
America/New_York    eine Zone, -05:00 im Winter und -04:00 im Sommer

"Europe/London" für eine Nutzerin zu speichern ist richtig, weil damit die Regel gespeichert wird. "UTC+1" zu speichern ist falsch, weil sich die Regel in einem halben Jahr bewegt und die Zahl nicht.

Dafür gibt es die IANA-Zeitzonendatenbank, und deshalb sehen ihre Bezeichner aus wie America/Los_Angeles und nicht wie PST³. Drei-Buchstaben-Kürzel sind mehrdeutig: CST ist US Central Standard Time bei UTC-6 und zugleich China Standard Time bei UTC+8, vierzehn Stunden auseinander. Die Datenbank wird ausserdem gepflegt, und das zählt, denn Regierungen ändern diese Regeln mit wenigen Wochen Vorlauf, und Ihre Laufzeitumgebung braucht das Update.

Unser Zeitzonen-Konverter arbeitet mit IANA-Namen, Umrechnungen über eine Umstellung hinweg sind also richtig und nicht ungefähr richtig.

Die Parse-Falle, die die meiste Zeit kostet

Diese eine lohnt sich zu merken, denn sie sieht aus wie ein Tippfehler und verhält sich wie ein Bug.

Eine reine Datumszeichenkette wird als UTC gelesen. Dasselbe Datum mit angehängter Uhrzeit und ohne Offset wird in der Ortszeit der Maschine gelesen¹. "2026-04-21" und "2026-04-21T00:00:00" liegen auf einer Maschine in New York also vier Stunden auseinander, in London null Stunden, und Ihre Testsuite läuft auf einem CI-Server in UTC, wo beide perfekt übereinstimmen.

Die Form mit Leerzeichen, "2026-04-21 14:40:00", ist überhaupt kein standardisiertes Format. Beide Engines akzeptieren sie und behandeln sie als Ortszeit, aber die Spezifikation verlangt das nicht, und MDN warnt, dass das Verhalten implementierungsabhängig ist¹.

Nur zwei dieser sechs Zeichenketten bedeuten überall dasselbe: die mit Z am Ende und die mit ausdrücklichem Offset.

Die zwei Stunden, die jeden März und November brechen

Die Lücke. Die US-Pazifikzeit geht am 8. März 2026 von 01:59:59 bei -08:00 direkt auf 03:00:00 bei -07:00. An diesem Tag zeigt nichts 02:30. Eine Erinnerung darauf hat keinen Zeitpunkt zum Auslösen, und Bibliotheken sind uneins, ob sie einen Fehler werfen oder still verschieben.

Die Faltung. Am 1. November 2026 fällt die Uhr zurück, und 01:30 kommt zweimal, eine Stunde auseinander. Die Mehrdeutigkeit dauert genau eine Stunde, und ein nach Ortszeit sortiertes Log ist über diese Stunde hinweg tatsächlich unsortiert.

Und die Umstellungen sind nicht weltweit gleich. Die EU stellt am letzten Sonntag im März um, drei Wochen nach den USA, in diesen drei Wochen ist der Abstand zwischen London und New York also nicht der, den der Code auf beiden Seiten unterstellt. Arizona stellt grösstenteils gar nicht um, Hawaii nicht, und weite Teile der Tropen nie.

Die Regeln, die all das verhindern

Für Vergangenes einen Zeitpunkt speichern, für Künftiges eine Regel. Was passiert ist, ist ein UTC-Zeitstempel. Was geplant ist, ist eine Uhrzeit plus IANA-Zone. "Montags 09:00 in New York, wöchentlich" als UTC-Zeitpunkt gespeichert verrutscht zweimal im Jahr um eine Stunde, als Regel gespeichert nicht.

Nie mit Ortszeit rechnen. 24 Stunden auf eine Ortszeitangabe zu addieren erreicht nicht verlässlich dieselbe Uhrzeit am nächsten Tag. Auf den Zeitpunkt addieren, dann formatieren.

Nie eine Zeichenkette parsen, deren Zone Sie nicht kennen. Siehe oben. Ohne Z und ohne Offset hängt ihre Bedeutung von der Maschine ab.

Nach ISO 8601 mit Offset serialisieren.

2026-04-21T14:40:00Z          UTC
2026-04-21T14:40:00.123Z      mit Millisekunden
2026-04-21T10:40:00-04:00     derselbe Zeitpunkt, New York

Als Text sortierbar, eindeutig, von allem parsbar. Vermeiden Sie MM/DD/YYYY gegen DD/MM/YYYY, wo 02/03/2026 je nach Leserin zwei verschiedene Tage sind, und alles ganz ohne Zone. Unser Datums-Formatierer rechnet zwischen Darstellungen um, ohne den Zeitpunkt darunter zu verlieren.

Was Temporal ändert

Der ganze bisherige Artikel ist eine Liste von Umgehungen für eine API von 1995. Temporal ist der Ersatz, und er ist inzwischen in Browsern: Chromium 147 und Firefox 148 stellen ihn bereit, und beide akzeptieren eine zonenbehaftete Zeichenkette der Form 2026-03-08T01:30:00-08:00[America/Los_Angeles].

Das Wesentliche ist, dass Temporal die Unterscheidung, um die sich dieser Artikel bemüht, zu einer Typunterscheidung macht statt zu einer Disziplin²:

• Temporal.Instant ist ein Moment, ohne Zone und ohne Kalender.
• Temporal.ZonedDateTime ist ein Moment plus die Zone, in der er zu lesen ist, serialisiert nach RFC 9557 mit der Zonenkennung in eckigen Klammern, sodass die Regel am Wert hängen bleibt.
• Die Plain-Typen sind Uhrzeitangaben, die absichtlich keinen Zeitpunkt haben, und genau das ist ein wiederkehrender Termin.

Objekte sind unveränderlich, Arithmetik ist ausdrücklich, und das Zeichenkettenformat trägt den Zonennamen statt nur einen Offset. Letzteres löst das Problem wiederkehrender Termine auf der Serialisierungsebene, was vorher nichts tat.

MDN führt Temporal weiterhin als eingeschränkt verfügbar², produktiver Code will also vorerst ein Polyfill. Dagegen zu schreiben lohnt sich trotzdem, weil die API genau die Fragen erzwingt, die dieser Artikel zu stellen empfiehlt.

Y2038, ein grep wert

Eine vorzeichenbehaftete 32-Bit-Zählung von Sekunden läuft bei 2.147.483.647 über, das ist der 19. Januar 2038 um 03:14:07 UTC, und springt auf Dezember 1901. Die meisten Systeme sind vor Jahren auf 64 Bit gewechselt. Eingebettete Geräte, alte Dateiformate und jedes Schema, das einen Zeitstempel in eine 32-Bit-Spalte gepackt hat, nicht.

Die Behebung ist trivial, die Bestandsaufnahme nicht, und so sind diese Dinge meistens.

Über Zonen hinweg arbeiten

Legen Sie eine Bezugszone fest und sagen Sie es, denn "Donnerstag 9 Uhr" ist keine Information. Schreiben Sie Zeitangaben mit Kennzeichnung: "15. März, 14:00 UTC" übersteht das Weiterleiten, "14 Uhr" nicht. Und für die tägliche Frage, wie spät es anderswo ist, beantwortet die Weltzeituhr das schneller als Kopfrechnen.

UTC im Speicher, IANA-Namen für Regeln, ISO 8601 mit Offset auf der Leitung. Diese drei decken fast alles ab, und Temporal macht sie allmählich zum Weg des geringsten Widerstands statt zu einer Disziplin, die man aufrechterhalten muss.