Epoch Time, erklärt: Die Uhr, die nur vorwärts tickt

In einem Satz

Epoch Time ist die Art und Weise, wie ein Computer die Zeit als eine einzige, ständig wachsende Zahl verfolgt: die Gesamtzahl der Sekunden, die seit Mitternacht UTC am 1. Januar 1970 vergangen sind.

Welches Problem es löst

Menschen und die Zeit haben eine komplizierte Beziehung. Wir haben Zeitzonen, Sommerzeit und Formate wie MM/TT/JJJJ im Vergleich zu TT.MM.JJJJ. Wir schreiben „8. Oktober 2024 um 15:00 Uhr“, aber das bedeutet in Tokio etwas anderes als in Toronto. Es ist ein einziges Chaos voller Unklarheiten.

Computer hingegen hassen Mehrdeutigkeit. Sie brauchen eine einzige, universelle und mathematisch einfache Methode, um einen Zeitpunkt darzustellen. Der Versuch, mit „8. Oktober“ zu rechnen, ist ein Albtraum. Aber mit einer ganz normalen Zahl zu rechnen? Genau dafür sind Computer gemacht.

Das ist das Problem, für dessen Lösung die Unixzeit (auch Epoch Time oder POSIX-Zeit genannt) geschaffen wurde. In den Anfängen des Unix-Betriebssystems in den 1970er Jahren brauchten die Entwickler ein unkompliziertes System zur Zeitmessung. Sie beschlossen, einen willkürlichen Startpunkt – eine „Epoche“ – zu wählen und einfach… zu zählen.

Die gewählte Epoche war 00:00:00 UTC, 1. Januar 1970. Warum gerade dann? Es war eine schöne, runde Zahl und für die damalige Technologie aktuell genug.

Von diesem Moment an erhöht jede vergehende Sekunde einen universellen Zähler. Anstatt dass ein Computer also „15:00 Uhr am 8. Oktober 2024 in Toronto (was EDT ist)“ parsen muss, kann er einfach die Zahl 1728409200 speichern. Diese Zahl repräsentiert genau diesen Moment, überall auf der Welt, gleichzeitig. Keine Zeitzonen, keine Formate, kein „Ist es AM oder PM?“. Einfach nur eine Zahl. Problem gelöst.

Wie es unter der Haube funktioniert

Im Kern ist das Konzept kinderleicht. Aber wie bei allem in der Technik steckt der Teufel im Detail.

Die Epoche und die Einheit

Das gesamte System basiert auf zwei Ideen:

Der Startpunkt (Epoche): Dieser ist auf 1970-01-01T00:00:00Z festgelegt. Das Z steht für Zulu, ein militärischer und luftfahrttechnischer Begriff für UTC (Koordinierte Weltzeit). In der Welt der Epoch Time ist dieser Moment einfach 0.
Die Maßeinheit: Die standardmäßige, offizielle Einheit ist die Sekunde.

Der Zeitstempel 1 repräsentiert also 1970-01-01T00:00:01Z. Der Zeitstempel für den Beginn des nächsten Tages, 1970-01-02T00:00:00Z, ist 86400 (denn es gibt 60 Sekunden * 60 Minuten * 24 Stunden = 86.400 Sekunden pro Tag).

// Ein Datum weit in der Zukunft
const humanDate = new Date('2035-10-26T10:00:00Z');

// Sein entsprechender Epoch-Zeitstempel in Sekunden
const epochTimestamp = 2071754400;

Wenn dein Computer dir diesen Zeitstempel als lokale Zeit anzeigt, führt er im Hintergrund eine Konvertierung durch. Er nimmt den universellen UTC-Zeitstempel und wendet den Zeitzonen-Offset deines Systems an, um ihn für dich verständlich darzustellen. Die zugrunde liegende Zahl bleibt jedoch rein und universell.

Variationen: Millisekunden, Mikrosekunden, Nanosekunden

Manchmal muss man Dinge messen, die schneller als eine Sekunde passieren. Dafür verwenden Systeme präzisere Versionen des Epoch-Zeitstempels. Das Prinzip ist dasselbe, aber die Einheit ändert sich.

Einheit	Beispielwert (für denselben Moment)	Übliche Stellenzahl	Typischer Anwendungsfall
Sekunden	`1728409200`	10	Der POSIX-Standard; APIs, Datenbanken.
Millisekunden	`1728409200123`	13	JavaScript (`Date.now()`), moderne APIs.
Mikrosekunden	`1728409200123456`	16	Hochleistungssysteme, einige Datenbanken.
Nanosekunden	`1728409200123456789`	19	Wissenschaftliches Rechnen, Sprache Go.

Dies ist die häufigste Fehlerquelle bei der Arbeit mit Zeitstempeln. Wenn ein System dir eine 13-stellige Zahl gibt und du sie als Sekunden behandelst, versuchst du, ein Datum zu berechnen, das Tausende von Jahren in der Zukunft liegt. Überprüfe immer die Doku oder schau dir die Anzahl der Stellen an, um zu wissen, womit du es zu tun hast.

Das „Jahr-2038-Problem“

Hier ist ein Klassiker aus der Computer-Folklore. Viele frühe Systeme speicherten den Epoch-Zeitstempel als vorzeichenbehaftete 32-Bit-Ganzzahl (signed integer), um wertvollen Speicher zu sparen.

Ein „Bit“ ist eine 1 oder eine 0. „32-Bit“ bedeutet, du hast 32 Plätze für 1en und 0en. „Vorzeichenbehaftet“ bedeutet, dass eines dieser Bits verwendet wird, um anzugeben, ob die Zahl positiv oder negativ ist. Das lässt 31 Bits für die Zahl selbst übrig, was einen Maximalwert von 2^31 - 1 oder 2.147.483.647 darstellen kann.

Was passiert, wenn die Anzahl der Sekunden seit 1970 dieses Limit erreicht? Es wird am Dienstag, 19. Januar 2038, um 03:14:07 UTC passieren. In der nächsten Sekunde wird die Ganzzahl überlaufen. Wie der Kilometerzähler eines Autos, der von 999999 auf 000000 umspringt, wird der 32-Bit-Zeitstempel auf seinen negativsten Wert (-2.147.483.648) zurückspringen. Das entspricht einem Datum im Dezember 1901.

Für jedes 32-Bit-System, das nicht gepatcht wurde, wird dies ein chronologisches Chaos verursachen. Denk an eingebettete Systeme in älteren Autos, Industrieanlagen oder Netzwerkroutern.

Die Lösung? Eine 64-Bit-Ganzzahl verwenden. Eine 64-Bit-Ganzzahl kann eine so unvorstellbar große Zahl speichern, dass sie für etwa 292 Milliarden Jahre nicht überlaufen wird. Bis dahin wird die Sonne die Erde längst verschluckt haben, also können wir das wohl als dauerhafte Lösung betrachten. Die meisten modernen Betriebssysteme und Sprachen haben den Wechsel bereits vollzogen.

Schaltsekunden: Der Haken an der Sache

Die Erdrotation ist nicht perfekt regelmäßig; sie verlangsamt sich leicht. Um unsere Atomuhren (die super regelmäßig sind) mit dem Sonnentag zu synchronisieren, fügen internationale Gremien gelegentlich eine „Schaltsekunde“ zum Kalender hinzu. Das bedeutet, eine Minute könnte 61 Sekunden haben (z. B. 23:59:60).

Wie geht die Epoch Time damit um? Gar nicht.

Offiziell ignoriert der POSIX-Standard Schaltsekunden. Er geht davon aus, dass jeder Tag genau 86.400 Sekunden hat. Wenn eine Schaltsekunde auftritt, handhaben Systeme dies auf verschiedene Weisen, aber eine gängige Methode ist es, die vorherige Sekunde praktisch zu wiederholen. Der Zeitstempel für 23:59:59 könnte zweimal auftreten. Dies erhält den kontinuierlichen, ununterbrochenen Sekundenzähler bei, bedeutet aber, dass ein Unix-Zeitstempel nicht immer perfekt auf die reale UTC-Zeit abgebildet werden kann. Für 99,9 % der Anwendungen ist das kein Problem. Für Hochfrequenzhandel oder wissenschaftliche Messungen ist es jedoch ein riesiges Kopfzerbrechen.

Geschichten aus der Praxis

Der Fall des zeitreisenden Caches

Ein Entwicklerteam startete ein neues Feature, das von einem Caching-System unterstützt wurde. Um die Performance zu verbessern, speicherten sie Daten für eine Stunde im Cache. Die Logik war einfach: expiration_time = current_time() + 3600. Sie verteilten den Code auf ihre Serverflotte.

Plötzlich hagelte es seltsame Fehler. Daten verschwanden fast sofort aus dem Cache. Nach Stunden hektischer Fehlersuche fanden sie den Übeltäter. Einer der neuen Server in der Flotte hatte seine Systemuhr falsch eingestellt – sie lief fünf Minuten hinter allen anderen Servern.

Wenn die Anfrage eines Benutzers auf einem korrekten Server landete, wurden die Daten mit einer Ablaufzeit von, sagen wir, 1678886400 (12:00 Uhr) gecacht. Wenn eine nachfolgende Anfrage für dieselben Daten auf dem „langsamen“ Server landete, zeigte dessen Uhr 11:55 Uhr an. Als er den Cache überprüfte, sah er eine Ablaufzeit von 12:00 Uhr und lieferte die Daten korrekt aus. Aber wenn die erste Anfrage auf dem langsamen Server landete, setzte dieser eine Ablaufzeit von 1678882800 (11:00 Uhr, seine eigene Zeit, plus eine Stunde, was 12:00 Uhr ist). Aber es war 11:55 Uhr. Moment, das stimmt nicht.

Versuchen wir es nochmal. Server A hat die Zeit 12:00 Uhr. Er setzt eine Cache-Ablaufzeit auf 12:00 + 1 Stunde = 13:00. Die Uhr von Server B geht nach; sie denkt, es sei 11:55 Uhr. Wenn Server B in den Cache schreiben muss, setzt er eine Ablaufzeit von 11:55 + 1 Stunde = 12:55. Wenn nun Server A einen Eintrag sieht, der um 12:55 Uhr abläuft, denkt er, er habe noch 55 Minuten, während Server B denkt, er habe eine volle Stunde. Das führt zu Inkonsistenzen.

Das wahre Chaos beginnt, wenn die Uhren stark voneinander abweichen. Wenn die Uhr von Server B eine Stunde zurückgestellt wäre (denkt, es ist 11:00 Uhr, obwohl es 12:00 Uhr ist), würde er eine Ablaufzeit von 11:00 + 1 Stunde = 12:00 setzen. Aus der Perspektive von Server A läuft dieser neue Cache-Eintrag in der Sekunde ab, in der er erstellt wurde. Die Daten waren praktisch sofort verschwunden.

Lektion: Unix-Zeitstempel sind absolut, aber sie werden von Systemuhren erzeugt, die es möglicherweise nicht sind. In verteilten Systemen ist die Synchronisation der Uhren (normalerweise mit dem Network Time Protocol, oder NTP) nicht nur eine gute Praxis, sondern absolut entscheidend.

Die API, die in Millisekunden sprach

Ein Frontend-Entwickler baute ein Dashboard zur Anzeige von Benutzeraktivitäten. Die Backend-API lieferte ein last_login-Feld mit einem Zeitstempel, wie 1678886400. Der Entwickler verwendete eine JavaScript-Bibliothek, um dies anzuzeigen: new Date(1678886400).

Das Ergebnis war bizarr. Der letzte Login jedes Benutzers wurde als „20. Januar 1970“ angezeigt. Was war da los?

Der Entwickler verbrachte eine Stunde damit, die Bibliothek, seinen Code und die Mondphase zu beschuldigen. Schließlich versuchte er, einen anderen Endpunkt derselben API zu integrieren. Diesmal lautete der Zeitstempel 1678886400123. Er hatte 13 Ziffern! Plötzlich machte es Klick. Der Konstruktor des Date-Objekts von JavaScript erwartet einen Zeitstempel in Millisekunden, nicht in Sekunden.

Das Backend sendete einen standardmäßigen 10-stelligen Zeitstempel auf Sekundenbasis. Das Frontend interpretierte 1.678.886.400 als die Anzahl der Millisekunden seit der Epoche, was einem Datum nur wenige Wochen nach Beginn der Epoche im Jahr 1970 entspricht. Die Lösung war einfach: new Date(1678886400 * 1000).

Lektion: Überprüfe immer, immer, immer die Genauigkeit eines Zeitstempels. Ein Unterschied von drei Nullen ist der Unterschied zwischen heute und 1970.

Häufige Fehler und Fallstricke

Die Zeitzone vergessen. Unix-Zeitstempel sind immer und ohne Ausnahme in UTC. Wenn du einen in ein für Menschen lesbares Datum umwandelst, wird deine Programmiersprache oder dein Tool fast immer die lokale Zeitzone deines Computers verwenden. Das kann zu massiver Verwirrung führen, wenn du das nicht berücksichtigst. 1728409200 ist ein exakter Zeitpunkt, wird aber in New York als 06:00 und in Tokio als 19:00 angezeigt. Die Zahl ist die Wahrheit; die Anzeige ist eine Interpretation.
Sekunden und Millisekunden verwechseln. Das ist der klassische „Faktor-1000-Fehler“. Es ist der häufigste Fehler bei der Arbeit mit Zeitstempeln. Als Faustregel gilt: 10 Ziffern sind Sekunden, 13 Ziffern sind Millisekunden. Wenn du etwas anderes siehst, sei sehr misstrauisch.
Das Jahr-2038-Problem ignorieren. Wenn du eine Standard-Web-App in einer modernen Sprache entwickelst, bist du wahrscheinlich auf der sicheren Seite. Aber wenn du C-Code für ein eingebettetes IoT-Gerät, das Infotainmentsystem eines Autos schreibst oder ein altes 32-Bit-System wartest, ist der Y2038-Bug eine sehr reale, tickende Zeitbombe.
Mehrdeutige Strings zur Erzeugung von Zeitstempeln verwenden. Einen Zeitstempel aus einem String wie „15. März 2025 22:00 Uhr“ zu erstellen, ist eine Einladung zum Scheitern. Ist das in deiner lokalen Zeitzone? Der Zeitzone des Servers? UTC? Erzeuge Zeitstempel immer aus zeitzonenbewussten Objekten oder verwende explizite UTC-Strings (wie das ISO-8601-Format: 2025-03-15T22:00:00Z).

Warum du es auf dem Schirm haben solltest

Du kannst einfach kein moderner Entwickler sein und die Epoch Time nicht verstehen. Sie ist die Lingua Franca der Zeit in der Informatik. Du wirst ihr überall begegnen:

APIs: JSON-Payloads verwenden sie ständig für Felder wie createdAt, updatedAt und expires_at.
JWTs: Die exp (Ablaufzeit), iat (ausgestellt am) und nbf (nicht vor) Claims sind allesamt Standard-Unix-Zeitstempel.
Datenbanken: Die Zeit als einzelne Ganzzahl zu speichern ist oft effizienter für Indizierung und Speicherung als ein komplexer DATETIME-Typ.
Log-Dateien: Die Verwendung numerischer Zeitstempel macht es trivial, Ereignisse über Dutzende verschiedener Server und Dienste hinweg zu korrelieren, selbst wenn sie sich in unterschiedlichen Zeitzonen befinden.
Dateisysteme: Die meisten Dateisysteme speichern das Erstellungs- und Änderungsdatum von Dateien als Unix-Zeitstempel.

Wenn du verstehst, wie es funktioniert, kannst du eine ganze Klasse von kniffligen, zeitbezogenen Fehlern mit Zuversicht beheben. Es ermöglicht dir, die unordentliche menschliche Welt der Zeitzonen und Kalender zu durchdringen und über die Zeit so nachzudenken, wie es ein Computer tut: als eine einfache, geordnete Reihe von Zahlen.

Geh tiefer

Wikipedia: Unixzeit – Der umfassende Überblick über Geschichte, Funktionsweise und verwandte Probleme.
MDN Web Docs: Date.now() – Erklärt die Verwendung von millisekundengenauen Epoch-Zeitstempeln in JavaScript.
Das Jahr-2038-Problem – Ein detaillierter Blick auf die Ursachen und Folgen des 32-Bit-Integer-Überlaufs.
RFC 822: Standard for the Format of ARPA Internet Text Messages – Ein altes, aber grundlegendes Dokument, das textbasierte Datumsformate spezifiziert und die Komplexität zeigt, die die Unixzeit vermeidet.
A brief history of time zones – Kontext dazu, warum die Standardisierung der Zeit überhaupt so wichtig war.