Unix-Zeitstempel und Zeitzonen: Die Verwirrung, die Ihre Woche auffrisst

Daten sind die am harmlosesten gebrochene Domäne in der Softwareentwicklung. Jeder Entwickler glaubt, Zeit zu verstehen, bis am letzten Sonntag im März ein Produktionsfehler auftaucht, oder ein Benutzer in Samoa berichtet, dass sein Analyse-Dashboard Daten von morgen zeigt.

Das ist ein praktischer Überblick darüber, was ein Unix-Zeitstempel tatsächlich ist, wie Zeitzonen mit ihm interagieren und die kleine Menge an Regeln, die Teams davon abhalten, denselben Datumsfehler jedes Jahr zu wiederholen.

Was ein Unix-Zeitstempel ist

Ein Unix-Zeitstempel ist eine einzelne Zahl: seit 00:00:00 UTC am 1. Januar 1970 vergangene Sekunden, ohne Schaltsekunden.

Das ist alles. Es ist ein Zeitpunkt, ausgedrückt als Zählung. Keine Zeitzone ist angehängt, weil er immer gegen UTC gemessen wird. Zu jedem gegebenen Zeitpunkt gibt es einen korrekten Unix-Zeitstempel, und jede Maschine auf der Erde sollte ihm zustimmen.

Beispiel: Als ich das schreibe, beträgt der Unix-Zeitstempel etwa 1.761.000.000 - das ist der 21. April 2026, 14:40 UTC. In Tokio-Zeit (UTC+9) umgerechnet ist es der 21. April, 23:40 Uhr. In New York (UTC-4 während der Sommerzeit) ist es der 21. April, 10:40 Uhr. Gleicher Moment, drei verschiedene Ortszeit-Darstellungen davon.

Der Unix-Zeitstempel ist die universelle Referenz. Alles andere ist eine Anzeigeschicht.

Unser Unix-Zeitstempel-Konverter konvertiert zwischen der Zahl und dem menschenlesbaren Datum in jeder Zeitzone.

Sekunden, Millisekunden, Mikrosekunden

Die “Sekunden seit 1970”-Definition ist die klassische. In der Praxis sehen Sie drei Granularitäten:

• Sekunden (10 Stellen): 1761000000 - traditionelle Unix-Zeit
• Millisekunden (13 Stellen): 1761000000000 - JavaScripts Date.now()
• Mikrosekunden (16 Stellen): 1761000000000000 - einige Datenbanken, Protokollierungssysteme

Wenn Sie jemals einen Zeitstempel sehen, den Sie nicht erkennen, zählen Sie die Stellen. Wenn er so aussieht, als wäre er ungefähr jetzt, ist eine 10-stellige Zahl Sekunden und eine 13-stellige Zahl Millisekunden. Das falsch zu verstehen multipliziert Ihr Datum mit 1000, was im Testen normalerweise offensichtlich ist - “das Jahr 57.739” ist ein Hinweis.

Zeitzonen vs. Offsets

Das ist die Unterscheidung, die die meisten Probleme verursacht. Ein Offset ist eine feste Abweichung von UTC, geschrieben wie +05:30 oder -08:00. Eine Zeitzone ist eine Regel: “Europa/London verhält sich die meiste Zeit des Jahres wie UTC+0 und im Sommer wie UTC+1.”

+05:30              - Offset, immer gleich
Asia/Kolkata        - Zeitzone, immer +05:30 (kein Sommer)
Europe/London       - Zeitzone, +00:00 im Winter, +01:00 im Sommer
America/New_York    - Zeitzone, -05:00 im Winter, -04:00 im Sommer

“Europa/London” als Zeitzone eines Benutzers zu speichern ist korrekt, weil es die Regel kodiert. “UTC+1” zu speichern ist falsch, weil sich die Regel in sechs Monaten ändert und der Offset nicht mehr übereinstimmt.

Deshalb hat die IANA-tz-Datenbank (auch “Olson” oder “tzdata” genannt) Namen wie America/Los_Angeles statt PST oder UTC-8. Die Drei-Buchstaben-Abkürzungen sind mehrdeutig (CST ist sowohl Central Standard Time in den USA als auch China Standard Time, die 14 Stunden auseinanderliegen), und der Offset allein weiß nicht, wann sich die Regel ändert.

Unser Zeitzonenkonverter verwendet IANA-Zeitzonennamen und kennt den vollständigen Regelsatz für jeden - sodass die Konvertierung über die Sommerzeitgrenze korrekt funktioniert.

Sommerzeit: die vorhersehbare Katastrophe

Zweimal im Jahr stellen die meisten Sommerzeitregionen der Welt ihre Uhren um. Wenn die Uhr im März (USA) oder am letzten Sonntag im März (EU) “vorspringt”, existiert eine ganze Stunde lokal nicht. Wenn die Uhr im Herbst “zurückspringt”, findet ein einstündiger Bereich zweimal statt.

Konsequenzen:

• Frühjahrslücke: Das Einrichten eines Ereignisses für 02:30 Uhr am Tag des Frühlingsübergangs ist in den meisten US-Zeitzonen ungültig - diese Zeit existiert nicht.
• Herbstduplizierung: 01:30 Uhr am Tag des Herbstübergangs findet zweimal statt. “01:30 Uhr Ortszeit” ist für einen Bereich von mehreren Stunden an diesem Tag mehrdeutig.
• Sommerzeit gilt nicht einheitlich. Die EU-Daten unterscheiden sich von denen der USA. Arizona (größtenteils) beachtet keine Sommerzeit. Hawaii nicht. Viele tropische Regionen nicht.

Wenn Sie Ereignisse in Ortszeit planen - wiederkehrende Besprechungen zum Beispiel - speichern Sie die Zeitzone, nicht den UTC-Zeitstempel. Eine Besprechung um “9:00 Uhr Tokyo jeden Wochentag” bleibt um 9:00 Uhr Tokyo, auch wenn sich Tokyo nicht verschiebt, aber die Zeitzone des Entwicklers schon.

Wenn Sie Ereignisse protokollieren - wann ein Klick stattgefunden hat, wann eine Transaktion aufgetreten ist - speichern Sie den UTC-Zeitstempel. Die Ortszeit-Darstellung ist etwas, das Sie bei der Anzeigezeit berechnen, unter Kenntnis der Zeitzone des Betrachters.

ISO 8601: das einzige Datum-Zeit-Format, das Vertrauen verdient

ISO 8601 ist der internationale Standard zur Darstellung von Datum und Uhrzeit. Die kanonische Form sieht so aus:

2026-04-21T14:40:00Z              <- Z = UTC (auch +00:00 geschrieben)
2026-04-21T14:40:00.123Z          <- Millisekunden
2026-04-21T10:40:00-04:00         <- Offset (New York, Sommerzeit)
2026-04-21T09:40:00.000-05:00     <- Einsekundenauflosung ist optional

Es ist als Text sortierbar, eindeutig und von im Wesentlichen jeder Datum-Zeit-Bibliothek parsebar. Wenn Sie unsicher sind, serialisieren Sie Daten nach ISO 8601.

Zu vermeidende Formate im Austausch:

• MM/DD/YYYY (amerikanisch) vs. DD/MM/YYYY (europäisch) - 02/03/2026 ist der 2. Februar oder der 3. März, je nach Herkunft des Lesers.
• Jedes Format ohne Zeitzone - 2026-04-21 14:40:00 ist nutzlos, ohne zu wissen, welche Zeitzone der Sender verwendet hat.
• RFC 2822-Format (Mon, 21 Apr 2026 14:40:00 GMT) - parsebar, aber umständlich, und der Wochentagsname ist sprachabhängig.

Der Datumsformatierer konvertiert zwischen ISO 8601 und verschiedenen Anzeigeformaten, ohne den zugrunde liegenden Zeitstempel zu verlieren.

Die Regeln, die Datumsfehler verhindern

UTC speichern. Ortszeit anzeigen.

Das ist die grundlegende Regel. Ihre Datenbank sollte immer UTC-Zeitstempel speichern. Wenn Sie ein Datum einem Benutzer zeigen, konvertieren Sie es bei der Anzeigezeit in seine Zeitzone. Ein Datensatz, der am 12. März um 23:50 Uhr Pazifik erstellt wurde, sollte als 13. März um 06:50 Uhr UTC gespeichert werden. Der UTC-Wert ist kanonisch.

Niemals Datumsmathematik in Ortszeit durchführen.

“24 Stunden hinzufügen” in Ortszeit bringt Sie möglicherweise nicht zur gleichen Wanduhrzeit morgen - wenn Sie eine Sommerzeitgrenze überschritten haben, liegen Sie um eine Stunde daneben. “24 Stunden hinzufügen” zu einem UTC-Zeitstempel bringt Sie immer genau 24 Stunden später, und dann konvertieren Sie zur Anzeige.

Niemals einen Datum-String ohne eine explizite Zeitzoneannahme parsen.

new Date("2026-04-21 14:40:00") in JavaScript wird als Ortszeit interpretiert. Im Browser eines Benutzers ist das ein Zeitpunkt; im Browser eines anderen, ein anderer. Wenn Sie die Zeitzone nicht kennen, sind Ihre Daten falsch.

Benutzerseitige wiederkehrende Ereignisse mit einer Zeitzone speichern, nicht als UTC-Zeitpunkt.

“Jeden Montag um 9:00 Uhr New Yorker Zeit” ist eine Regel, die die America/New_York-Zeitzone bei jedem Vorkommen wiederverwendet. Als wiederkehrender UTC-Zeitstempel gespeichert, driftet er bei Sommerzeitänderungen um eine Stunde.

Warum das Y2038-Problem immer noch ein wenig relevant ist

Ein vorzeichenbehaftetes 32-Bit-Integer, das Unix-Sekunden hält, läuft bei 2.147.483.647 Sekunden über, was am 19. Januar 2038 um 03:14:07 UTC ist. Jedes System, das zu diesem Zeitpunkt noch 32-Bit-Zeitstempel verwendet, springt in eine negative Zahl und denkt, es sei 1901.

Das war früher ein großes Problem. Die meisten modernen Systeme sind zu 64-Bit-Zeitstempeln gewechselt. Einige eingebettete Systeme, Legacy-Datenbanken und alte Dateisysteme nicht. Wenn Sie Code pflegen, bei dem time_t noch 32-Bit ist, oder bei dem Zeitstempel in ein 32-Bit-Feld gepackt werden, ist 2038 ein echtes Problem.

Die Lösung ist die Verwendung von 64-Bit-Speicher. Die Herausforderung besteht darin, jede Stelle zu prüfen, an der ein Zeitstempel in einem älteren System lebt.

Über Zeitzonen hinweg arbeiten

Einige praktische Muster für Teams, die über Regionen hinweg arbeiten:

• Eine Standard-”Referenz”-Zeitzone für Operationen haben. Viele Unternehmen verwenden UTC sogar für interne Planung; andere verwenden die Hauptsitz-Zeitzone. Seien Sie explizit - “Donnerstag 9:00 Uhr” bedeutet ohne Qualifizierer nichts.
• Tools verwenden, die relativ und absolut zeigen. Die zeitzonen-bewussten Zeitstempel von Slack, die Ortszeit-Konvertierung von Google Kalender oder ein Tool wie der Weltzeituhr zur schnellen Überprüfung mehrerer Orte.
• Daten mit Zeitzonen-Etiketten schreiben. “15. März, 14:00 Uhr UTC” ist eindeutig. “15. März, 14:00 Uhr” hängt vollständig davon ab, wer liest.

Die Meta-Lektion

Daten in der Software sind keine Domäne, in der “gut genug” standhält. Jede Mehrdeutigkeit wird schließlich ausgeübt - vom letzten Kunden, der einen Fehler meldet, vom Sommerzeitumbruch, der nächsten Sonntag stattfindet, vom internationalen Teammitglied, dessen Montag der Sonntag aller anderen ist.

Die gute Nachricht ist, dass die Regeln klein und die Werkzeuge ausgereift sind. UTC im Speicher, IANA-Zeitzonen für Anzeigeregeln, ISO 8601 für den Austausch. Folgen Sie diesen dreien, und die meisten Datumsfehler, die Teams in ihrem ersten Jahr plagen, verschwinden.

Die schlechte Nachricht ist, dass jeder Entwickler die Regeln mindestens einmal auf die harte Tour lernen muss. Dieser Artikel ist ein Versuch, das abzukürzen.