Der komplette Leitfaden zu Unix-Zeitstempeln: Von der Epoche bis zum Jahr-2038-Problem

Öffnen Sie irgendein Backend-Log, eine Datenbanktabelle oder eine API-Antwort, und fast sicher entdecken Sie eine Zahl wie 1754467200. Das ist ein Unix-Zeitstempel — die Lingua franca der Zeit in der Informatik. Er sieht trivial einfach aus und ist in der Praxis doch ein Minenfeld: Drei zusätzliche Ziffern können Sie um Jahrtausende versetzen, Zeitzonen verursachen mysteriöse Acht-Stunden-Verschiebungen, und Altsysteme werden 2038 gemeinsam durch die Zeit reisen. Diese Anleitung erklärt, woher Zeitstempel kommen und wie Sie die klassischen Fallen vermeiden.

Was ist ein Unix-Zeitstempel?

Die Definition passt in einen Satz: die Anzahl der seit dem 1. Januar 1970, 00:00:00 UTC verstrichenen Sekunden. Dieser Startpunkt heißt Unix-Epoche. Zeitstempel 0 ist die Epoche selbst, und 1754467200 landet auf einen Moment im August 2026.

Warum 1970? Es war keine großartige Designentscheidung — es war ein historischer Zufall. Unix entstand um 1969–1971 bei Bell Labs, und frühe Versionen zählten die Zeit tatsächlich in 1/60-Sekunden-Ticks ab 1971. Ingenieure setzten den Ursprung später auf den 1. Januar 1970 zurück und wechselten auf ganze Sekunden: ein rundes Datum, das praktischerweise frisch war. Die Konvention verbreitete sich mit Unix und C, bis sie zum De-facto-Standard wurde — heute spricht sie praktisch jede Programmiersprache, Datenbank und jedes Netzwerkprotokoll. Eine nette Tatsache fürs Debuggen von Datumscode: Der 1. Januar 1970 war ein Donnerstag.

Falle Nr. 1: Sekunden vs. Millisekunden

Der klassische Unix-Zeitstempel zählt Sekunden, aber JavaScripts Date.now() und Javas System.currentTimeMillis() liefern Millisekunden. Dieses eine Wort steckt hinter mehr Zeit-Bugs als alles andere. Sie auseinanderzuhalten ist einfach:

Sekunden:       1754467200      (10 Ziffern)
Millisekunden:  1754467200000   (13 Ziffern)

Millisekunden als Sekunden zu parsen bringt 1754467200000 Sekunden irgendwo um das Jahr 57.600 unter — kein Fehler, nur ein still absurdes Datum. Sekunden als Millisekunden zu parsen lässt alles „kürzlich Erstellte“ als Mitte Januar 1970 erscheinen. Stoßen Sie auf eine verdächtige Zahl, fügen Sie sie in den Zeitstempel-Konverter ein und wechseln Sie zwischen Sekunden- und Millisekunden-Einheit, um zu sehen, welche Interpretation ein vernünftiges Datum ergibt. Es ist eine Zehn-Sekunden-Diagnose.

Auch den aktuellen Zeitstempel zu holen unterscheidet sich je nach Sprache — achten Sie auf die Einheit:

import time
int(time.time())        # Sekunden
int(time.time() * 1000) # Millisekunden

Math.floor(Date.now() / 1000)  // Sekunden
Date.now()                     // Millisekunden

Zeitstempel haben keine Zeitzone

Ein weiterer weit verbreiteter Irrtum ist, dass Zeitstempel eine Zeitzone „tragen“. Tun sie nicht. Ein Unix-Zeitstempel ist immer relativ zur UTC-Epoche — derselbe Augenblick ergibt überall auf der Erde dieselbe Zahl. Ein Nutzer in Peking und einer in New York, die in derselben Sekunde eine API aufrufen, erhalten identische Werte.

Zeitzonen kommen erst ins Spiel, wenn angezeigt wird, wenn der Zeitstempel gemäß einem lokalen Offset in eine lesbare Zeichenkette formatiert wird. Derselbe 1754467200 rendert als 2026-08-06 16:00:00 in UTC+8 und 2026-08-06 04:00:00 in UTC-4 — ein Augenblick, zwei Zeichenketten. Daraus folgt eine wichtige Engineering-Regel: Zeitstempel (oder UTC-Datetimes) speichern und übertragen und genau einmal in eine lokale Zeitzone umrechnen — bei der Darstellung. Wenn Sie vergleichen müssen, wie ein Moment in verschiedenen Regionen aussieht, zeigt die Weltuhr mehrere Städte nebeneinander, und der Datumsrechner ist praktisch, um Daten N Tage vor oder nach einem Zeitstempel zu bestimmen.

Das Jahr-2038-Problem

Altsysteme speichern Zeitstempel auf Sekundenebene in einer vorzeichenbehafteten 32-Bit-Ganzzahl, die bei 2147483647 ihr Maximum erreicht — entsprechend dem 19. Januar 2038, 03:14:07 UTC. Eine Sekunde später läuft der Zähler auf -2147483648 über, und das Datum wird als 13. Dezember 1901 interpretiert. Das ist das Jahr-2038-Problem, mechanisch identisch zum Y2K-Bug, nur mit anderen Ziffern.

Zu weit weg, um sich zu sorgen? Bedenken Sie heute unterzeichnete 15-Jahres-Hypotheken, Rentensysteme, eingebettete Geräte und industrielle Steuerungen — sie alle müssen bereits mit Daten nach 2038 umgehen. Die gute Nachricht: Moderne 64-Bit-Systeme nutzen 64-Bit-Ganzzahlen, die Zeiten weit jenseits des Alters des Universums darstellen, neuer Code ist also praktisch immun. Das echte Risiko lebt in ungepflegten Altsystemen, Firmware und Dateiformaten. Wenn Sie Low-Level- oder Embedded-Arbeit machen, stellen Sie sicher, dass Ihre Zeitfelder 64-Bit sind statt eines Alt-32-Bit-time_t.

Warum Unix-Zeit Schaltsekunden ignoriert

Die Erdrotation ändert sich langsam und unregelmäßig, um Atomuhren mit der astronomischen Zeit in Einklang zu halten, fügen Behörden gelegentlich eine Schaltsekunde ein — einen Tag, der wirklich 23:59:60 enthält. Seit 1972 wurden 27 Schaltsekunden hinzugefügt.

Unix-Zeit tut einfach so, als gäbe es keine Schaltsekunden: Jeder Tag ist als exakt 86.400 Sekunden definiert. Der Gewinn ist herrlich einfache Arithmetik — subtrahieren Sie zwei Zeitstempel und teilen Sie durch 86.400, haben Sie die Tage dazwischen. Der Preis ist eine Abweichung von bis zu etwa einer Sekunde von der echten Erdrotation. Betriebssysteme behandeln tatsächliche Schaltsekunden uneinheitlich (manche wiederholen eine Sekunde, andere „verschmieren“ sie über den Tag), weshalb Systeme, die streng monotone Zeit brauchen — Finanzhandel, verteilte Logs —, besondere Sorgfalt benötigen. Bemerkenswerterweise hat die internationale Metrologie-Gemeinschaft beschlossen, nach 2035 keine Schaltsekunden mehr einzufügen, diese Eigenheit ist also auf dem Rückzug.

Alltägliche Debugging-Tipps

Ein paar praktische Gewohnheiten für die Arbeit mit Zeitstempeln:

1. Zählen Sie zuerst die Ziffern: 10 Ziffern sind Sekunden, 13 Millisekunden, 16 Mikrosekunden. Falsche Länge → Einheit verdächtigen.
2. Multiplikation vs. Division mit 1000 beim Umrechnen zwischen Sekunden und Millisekunden ist ein Bug-Hotspot — ein zweiter Blick im Code-Review lohnt.
3. Zeitstempel- oder Datetime-Spalte in der Datenbank? Einen Zeitstempel (oder eine UTC-Datetime) zu speichern ist fast immer die sicherere Wahl; lassen Sie Zeitzonen der Darstellungsschicht.
4. Unlesbare Zahlen in Logs gehen direkt in den Zeitstempel-Konverter, der ISO-, UTC- und lokale Formate auf einmal zeigt, damit Sie den Moment sofort festnageln.
5. Brauchen Sie „welches Datum ist in N Tagen“ oder die Lücke zwischen zwei Daten? Der Datumsrechner ist schneller als Kopfrechnen und stolpert nicht über Monatslängen oder Schaltjahre.
6. Planung über Kontinente hinweg? Prüfen Sie zuerst die lokale Zeit aller in der Weltuhr und vermeiden Sie die klassische Verwechslung „dein Nachmittag — welcher Tag?“.

Der Unix-Zeitstempel ist eine der erfolgreichsten Konventionen der Software: eine Ganzzahl, überall verstanden. Haben Sie Epoche, Einheiten, die Zeitzonenfrage und das 32-Bit-Limit verinnerlicht, hat fast jeder zeitbezogene Bug, dem Sie begegnen, einen klaren Diagnosepfad.