Unix-Zeitstempel-Konverter

Die Stellen zählen

Das einzig wirklich Knifflige beim Lesen eines Zeitstempels ist, seine Einheit zu bestimmen, und die Größenordnung entscheidet das. In der Praxis gibt es keine Mehrdeutigkeit, weil sich die Bereiche für kein Datum überlappen, mit dem tatsächlich jemand arbeitet.

Sich zu irren bedeutet den Faktor tausend, das Ergebnis landet also entweder in den frühen 1970ern oder Zehntausende Jahre in der Zukunft. Offensichtlich, wenn man hinsieht; völlig unsichtbar, wenn es eine Spalte in einer Logtabelle ist — und genau dort beißt es.

Was Unix-Zeit tatsächlich zählt

Sekunden seit 00:00:00 UTC am 1. Januar 1970, unter der Annahme, dass jeder Tag genau 86.400 Sekunden lang ist.

Diese Annahme ist falsch. Alle paar Jahre werden Schaltsekunden eingefügt, damit die Atomzeit zur Erdrotation passt, die sich allmählich verlangsamt. Unix-Zeit bildet sie nicht ab — Systeme wiederholen eine Sekunde oder verteilen sie über einen Tag, damit die Zählung gleichmäßig bleibt.

Die Folge ist, dass Unix-Zeit keine echte Zählung der seit 1970 verstrichenen Sekunden ist; sie liegt rund siebenundzwanzig Sekunden zurück. Für Planung, Protokollierung und Ablauffristen ist das genau der richtige Kompromiss, denn gleichmäßige Arithmetik zählt mehr als astronomische Genauigkeit. Für alles, was wirklich verstrichene Dauer misst, nehmen Sie eine monotone Uhr — die Wanduhr kann außerdem zurückspringen, wenn NTP sie korrigiert.

Das Jahr-2038-Problem

Eine vorzeichenbehaftete 32-Bit-Ganzzahl fasst bis 2.147.483.647, als Unix-Zeitstempel also 03:14:07 UTC am 19. Januar 2038. Eine Sekunde später läuft sie ins Negative über, und das Datum wird Dezember 1901.

Alles Moderne nutzt 64 Bit und reicht für rund 292 Milliarden Jahre. Nicht modern sind: eingebettete Firmware, industrielle Steuerungen, manche älteren Datenbankspaltentypen und C-Code, der noch von einem 32-Bit-time_t ausgeht. Am stärksten gefährdet sind die Systeme, die niemand ansieht — genau das machte auch Y2K teuer.

Welches Format man tatsächlich nehmen sollte

ISO 8601 in UTC, für alles, was eine Grenze zwischen Systemen überschreitet oder von einem Menschen gelesen wird:

2026-08-27T14:30:00Z

Es ist eindeutig, sortiert als schlichte Zeichenkette korrekt und ist um zwei Uhr nachts in einem Log lesbar. Das Z zählt: Ohne es nehmen die meisten Parser Ortszeit an, und Sie haben einen Fehler erfunden, der sich nur bei Nutzern in anderen Ländern zeigt.

Unix-Sekunden sind intern in Ordnung — die Claims exp und iat in JWTs nutzen sie, und Ganzzahlvergleiche sind billig. Der Preis: Sie sind unleserlich und laden zur oben beschriebenen Einheitenverwechslung ein.

Zu vermeiden: jedes Format mit Offset, aber ohne Zonenkennung (+01:00 sagt Ihnen nicht, ob das BST oder CET ist, was bei künftigen Daten zählt), und alles aus dem Bereich 03/04/2026, was je nach Seite des Atlantiks zwei verschiedene Tage bedeutet.

Künftige Ereignisse speichern

Eine Feinheit, über die man stolpert. Für eine Besprechung um 09:00 im kommenden März ist UTC zu speichern falsch — ändern sich bis dahin die Zeitzonenregeln, und Regierungen ändern sie, verschiebt sich der Termin. Künftige lokale Ereignisse gehören als Ortszeit plus Zonenkennung (Europe/London) gespeichert und bei der Anzeige nach den dann geltenden Regeln umgerechnet. Bei vergangenen Ereignissen ist es umgekehrt: UTC, denn was geschehen ist, steht fest.

Verwandt

Die Claims exp und iat in JWTs sind Unix-Sekunden — der JWT-Decoder rechnet sie für Sie um und markiert den Ablauf. Wenn es ums Planen statt ums Umrechnen geht, zeigt der Cron-Parser, wann ein Zeitplan das nächste Mal auslöst.