Unix-Zeitstempel, Schaltsekunden und das Jahr-2038-Problem

Was der Zähler tatsächlich zählt

Unix-Zeit oder POSIX-Zeit ist definiert als Anzahl der seit 1970-01-01T00:00:00Z verstrichenen Sekunden unter der Annahme, dass jeder Tag genau 86 400 Sekunden enthält. Die Definition ist arithmetisch, nicht beobachtend: Die Spezifikation gibt eine Formel aus Jahr, Tag des Jahres, Stunde, Minute und Sekunde an, und diese Formel hat keinen Term für Schaltsekunden, weil Schaltsekunden in ihr nicht existieren.

Die Folge sollte man unumwunden sagen, denn dort beginnt die meiste Verwirrung: Ein Unix-Zeitstempel ist keine Zählung physikalischer Sekunden. Er ist eine komprimierte Darstellung eines UTC-Kalenderdatums mit Uhrzeit. Zwei Zeitstempel im Abstand von 86 400 liegen konstruktionsbedingt immer genau einen UTC-Tag auseinander, ganz gleich, was eine Cäsiumuhr über dasselbe Intervall gemessen hat.

Ein Vorbehalt, denn die Eigenschaft wird oft überzogen. Sie gilt in UTC, nicht in Ortszeit. An echten Zeitzonendaten gemessen lagen zwischen lokaler Mitternacht und lokaler Mitternacht in Europe/Paris am 2026-03-29 nur 82 800 Unix-Sekunden und am 2026-10-25 ganze 90 000, gegenüber 86 400 an einem gewöhnlichen Tag; America/New_York ergab am 2026-03-08 ebenfalls 82 800. Sommerzeit ändert den Zähler nicht — sie ändert, wie viele Zählschritte in einen lokalen Kalendertag passen. Genau deshalb gehören Zeitstempel als UTC-Instanten gespeichert und erst zur Anzeige umgerechnet.

Der Tausch: keine Schaltsekunden, keine Tabelle

Der Ausschluss von Schaltsekunden wirkt wie ein Mangel, bis man die Alternative betrachtet. Zählte der Zähler physikalische Sekunden, müsste man zur Umwandlung eines Zeitstempels in ein Datum jede zwischen Epoche und Zeitstempel eingefügte Schaltsekunde kennen. Schaltsekunden werden vom IERS wenige Monate im Voraus auf Basis von Messungen der Erdrotation angekündigt; diese Tabelle lässt sich also nicht berechnen, nur verteilen. Jedes Gerät bräuchte sie aktuell, und jedes Gerät mit veralteter Tabelle würde aus derselben Zahl ein anderes Kalenderdatum errechnen.

Der Entwurf wählte Determinismus vor physikalischer Genauigkeit, und der Lohn ist, dass Zeitstempelarithmetik überall ohne gemeinsamen Zustand funktioniert. Ein Telefon, das nie eine Netzverbindung hatte, errechnet aus 1786752000 exakt dasselbe Datum wie eine Rechenzentrumsuhr. Die Division durch 86 400 stimmt. Einen Tag addieren heißt 86 400 addieren. Nach Zeitstempel sortieren sortiert nach Zeit. Nichts davon überlebte eine Definition in physikalischen Sekunden.

Der Preis wird an genau einer Stelle gezahlt: Jede Berechnung einer physikalischen Dauer über eine Schaltsekunde hinweg irrt um die Zahl der überquerten Schaltsekunden. Zwischen 2016-12-31T00:00:00Z und 2017-01-01T00:00:00Z beträgt die Unix-Differenz 86 400, während tatsächlich 86 401 SI-Sekunden vergingen. Für fast jede Anwendung ist dieser Fehler bedeutungslos. Für Satellitenentfernungsmessung, die Reihenfolge von Finanzgeschäften im Sub-Sekunden-Bereich und physikalische Zeitmessung ist er es nicht, und diese Bereiche nutzen stattdessen TAI oder GPS-Zeit — monotone Skalen ganz ohne Schaltsekunden.

Was eine Schaltsekunde mit dem Zähler macht

UTC fügt eine Schaltsekunde ein, indem eine Minute 61 Sekunden enthalten darf, wobei die zusätzliche Sekunde als 23:59:60 bezeichnet wird. Seit 1972 wurden siebenundzwanzig eingefügt — TAI minus UTC betrug am 1972-01-01 zehn Sekunden und beträgt seit 2017-01-01 siebenunddreißig, und die Differenz ist genau die Anzahl. Alle waren positiv; eine negative Schaltsekunde, die eine Sekunde entfernt, ist von der Norm erlaubt und wurde nie verwendet.

Eine POSIX-Uhr hat keine Darstellung für die Sekunde mit der Nummer 60, also muss etwas nachgeben. Das klassische Verhalten ist Wiederholung: Der Zähler gibt denselben Wert zweimal aus, eine Sekunde ist nicht monoton, und jeder Code, der streng steigende Zeitstempel voraussetzt, sieht ein Duplikat. Manche Systeme frieren den Zähler stattdessen eine Sekunde lang ein. Beides ist für Anwendungen sichtbar, und beides hat echte Ausfälle in Systemen verursacht, die einen Zeitstempel als eindeutigen Schlüssel oder als streng steigende Folgenummer behandelten.

Die pragmatische Antwort, auf die sich große Betreiber geeinigt haben, ist Smearing: die zusätzliche Sekunde über ein Fenster von Stunden zu verteilen, sodass keine Uhr je wiederholt oder stehen bleibt — zum Preis, dass jede Uhr im Fenster leicht falsch geht. Das zählt jedes Jahr weniger, denn im November 2022 beschloss die 27. Generalkonferenz für Maß und Gewicht, spätestens bis 2035 keine Schaltsekunden mehr einzufügen und UTC weiter als bisher von der Sonnenzeit abweichen zu lassen. Der Mechanismus ist noch offen, die Richtung nicht: Die Schaltsekunde wird abgeschafft.

2038, exakt berechnet

Eine vorzeichenbehaftete 32-Bit-Ganzzahl reicht von −2 147 483 648 bis 2 147 483 647. Als Sekunden seit der Epoche gelesen ist das Maximum 2038-01-19T03:14:07Z. Speichert man 2 147 483 648 in einen echten vorzeichenbehafteten 32-Bit-Platz und liest zurück, erhält man −2 147 483 648, also 1901-12-13T20:45:52Z. 2 147 483 649 ergibt 1901-12-13T20:45:53Z. Der Fehler ist kein Absturz und keine Fehlermeldung, sondern ein Datum 136 Jahre in der Vergangenheit, still geliefert und weiterverwendet.

Zwei benachbarte Tatsachen sind wissenswert. Ein vorzeichenloser 32-Bit-Zähler erreicht 4 294 967 295, also 2106-02-07T06:28:15Z — ein verbreiteter Behelf in Embedded-Firmware, der das Problem nur verschiebt und Daten vor 1970 undarstellbar macht. Und ein vorzeichenbehaftetes 64-Bit-time_t erreicht 9 223 372 036 854 775 807 Sekunden, rund 292 Milliarden Jahre, etwa das Einundzwanzigfache des heutigen Weltalters. Das ist keine Verschiebung, sondern eine dauerhafte Lösung.

Das Datum, das Sorge machen sollte, ist nicht 2038, sondern heute, denn zuerst brechen die Systeme, die künftige Zeitpunkte berechnen. Vom 2026-08-15 aus liegt der Überlauf 360 731 647 Sekunden entfernt — 4 175 Tage oder 11,43 Jahre. Ein Zehnjahreshorizont ab diesem Datum endet am 2036-08-14 und passt noch. Ein Fünfzehnjahreshorizont endet am 2041-08-14 und passt nicht. Alles, was ein Ablaufdatum, einen Tilgungsplan, eine Aufbewahrungsfrist oder eine Zertifikatslaufzeit von mehr als etwa elfeinhalb Jahren speichert, erzeugt bereits Werte, die ein 32-Bit-Feld nicht fassen kann.

Was 2026 gefährdet ist und was nicht

Verbreitete 64-Bit-Betriebssysteme sind in Ordnung, und das seit Jahren. Auf der für diesen Artikel genutzten Maschine beträgt sizeof(time_t) 8 Byte, und der Shell-Befehl date -u -r 2147483648 gibt Tue Jan 19 03:14:08 UTC 2038 aus, ganz ohne Überlauf. Dasselbe gilt für jedes aktuelle 64-Bit-Linux, -macOS und -Windows. JavaScript war nie betroffen: Ein Date hält einen float64-Millisekundenzähler, und die Spezifikation begrenzt dessen Bereich auf plus/minus 8 640 000 000 000 000 Millisekunden, was von −271821-04-20 bis +275760-09-13 reicht.

Die verbleibende Angriffsfläche ist schmal, aber real, und sie liegt eher in Feldern als in Prozessoren. Spaltentypen mit dokumentiertem 32-Bit-Bereich sind der häufigste Fall: MySQLs TIMESTAMP endet spezifikationsgemäß am 2038-01-19 03:14:07 UTC, sein DATETIME-Typ dagegen ist nicht betroffen. Draht- und Dateiformate, die ein 32-Bit-Feld festlegen, lassen sich ohne Versionssprung nicht verbreitern. Embedded-Firmware auf 32-Bit-Mikrocontrollern nutzt aus Speichergründen häufig bewusst einen 32-Bit-Zähler. Und jede Codebasis, die eine Epochensekunde in einem ausdrücklich 32-bittigen Typ ablegt — eine int32-Spalte, ein Binärsatz fester Breite, eine für ein 32-Bit-Ziel kompilierte C-Struktur —, trägt die Grenze unabhängig vom darunterliegenden Betriebssystem.

Die praktische Prüfung ist kurz. Suche nach int32- und INTEGER-Spalten, die Epochensekunden halten; prüfe den dokumentierten Bereich jedes verwendeten Zeitstempel-Spaltentyps; suche Binärsätze fester Breite und jede für ein 32-Bit-Ziel kompilierte Struktur; und teste mit dem Wert 2147483648, statt zu warten. Lässt sich ein Feld nicht verbreitern, sind eine ISO-8601-Zeichenkette oder ein 64-Bit-Millisekundenzähler beide gute Alternativen, und beide kosten mehr Bytes, als sie an Diskussionen sparen.

Sekunden oder Millisekunden: der Faktor-1000-Fehler

Das ist mit Abstand der häufigste Zeitstempelfehler, und er ist reine Einheitensache. Unix-Werkzeuge, die meisten APIs und die POSIX-Definition verwenden Sekunden. JavaScript, Java und sehr viele Web-APIs verwenden Millisekunden. Beide sind dieselbe Zahl im Verhältnis 1 000, und keine ist im Übertragungsformat gekennzeichnet — eine Verwechslung bleibt unsichtbar, bis ein Datum angezeigt wird.

Beide Richtungen liefern ein absurdes Ergebnis, und das ist die gute Nachricht. Nimm 2026-08-15T00:00:00Z: in Sekunden 1786752000, in Millisekunden 1786752000000. Gibst du den Sekundenwert an etwas, das Millisekunden erwartet, erhältst du 1970-01-21T16:19:12Z — drei Wochen nach der Epoche, denn 1,79 Milliarden Millisekunden sind nur rund zwanzig Tage. Gibst du den Millisekundenwert an etwas, das Sekunden erwartet, erhältst du das Jahr 58589, genauer +058589-12-01T00:00:00Z. Beides ist so weit vom Plausiblen entfernt, dass eine einzige Stichprobe es auffliegen lässt.

Die funktionierende Faustregel: Ein aktueller Zeitstempel hat in Sekunden zehn Stellen, in Millisekunden dreizehn. Zehn Stellen bleiben bis 2286 richtig. Besser als eine Faustregel ist ein Feldname, bei dem die Einheit nicht misszuverstehen ist — expiresAtSeconds statt expiresAt — oder eine RFC-3339-Zeichenkette über die Grenze zu tragen und beim Empfang zu parsen: selbstbeschreibend und ein paar Dutzend Byte teuer.

Zeit so speichern, dass sie überlebt

Speichere den Zeitpunkt, nicht die Darstellung. Ein Zeitpunkt ist eine Stelle auf der Zeitachse und wird durch einen UTC-Zeitstempel ausreichender Breite vollständig festgelegt — eine 64-Bit-Epochensekunde, ein 64-Bit-Millisekundenzähler oder eine mit Z endende RFC-3339-Zeichenkette. Eine Darstellung ist das, was ein Mensch an einem bestimmten Ort sähe, und sie hängt von Zeitzonenregeln ab, die Regierungen mit wenigen Wochen Vorlauf ändern. Die Darstellung zu speichern heißt, eine Antwort zu speichern, die rückwirkend falsch werden kann.

Eine Ausnahme sollte man benennen, denn UTC zu speichern wird oft als universeller Rat verkauft. Ein künftiger Termin an einem benannten Ort ist kein Zeitpunkt, sondern eine Wanduhrzeit in einer Rechtsordnung, und verstellt diese ihre Uhren, ändert sich der korrekte Zeitpunkt. Ein Treffen um 09:00 in Berlin im kommenden November gehört als lokales Datum, lokale Uhrzeit und IANA-Zonenkennung gespeichert und erst bei Bedarf zu einem Zeitpunkt aufgelöst. Speichere UTC für Geschehenes und Ortszeit plus Zonenname für Geplantes.

Darüber hinaus nehmen drei Gewohnheiten den größten Teil des verbleibenden Ärgers. Gib jedem Zeitstempelfeld die Einheit in den Namen, damit niemand zwischen Sekunden und Millisekunden raten muss. Verwende überall einen 64-Bit-Typ, auch in der Datenbankspalte, damit 2038 eine historische Kuriosität statt einer Frist ist. Und behandle einen Zeitstempel nie als eindeutigen Bezeichner oder monotone Folgenummer, denn Schaltsekundenbehandlung, Uhrkorrekturen und Migrationen virtueller Maschinen können denselben Wert zweimal erscheinen oder die Zeit kurz rückwärts laufen lassen.

Häufige Fragen

Ist ein Unix-Zeitstempel in UTC oder in meiner Ortszeit?

Streng genommen keines von beidem, und das ist die brauchbare Denkweise. Ein Unix-Zeitstempel bezeichnet einen Punkt auf der Zeitachse. Er trägt gar keine Zeitzone, weil er keine braucht — die Zahl 1786752000 meint überall auf der Erde denselben Moment. Richtig ist, dass die Umwandlung in ein lesbares Datum eine Zone erfordert und dass die Epoche auf 1970-01-01T00:00:00 UTC verankert ist; eine Umwandlung ohne angegebene Zone liefert also UTC. Deshalb ist ein Zeitstempel das Richtige zum Speichern und Übertragen und das Falsche zum Anzeigen: Die Speicherschicht braucht einen eindeutigen Zeitpunkt, die Darstellungsschicht Zone, Locale und Kalender. Der übliche Fehler ist, mitten in einer Verarbeitungskette in Ortszeit umzuwandeln und das Ergebnis zu speichern — das brennt die Zone einer Maschine ein und verschiebt still jeden Wert um deren Versatz. Wandle einmal um, so spät wie möglich, in der Oberfläche.

Was genau passiert am 19. Januar 2038 um 03:14:07?

In jedem System, das den Zeitstempel in einer vorzeichenbehafteten 32-Bit-Ganzzahl hält, erreicht der Zähler 2 147 483 647, und der nächste Schritt läuft über. In einem echten vorzeichenbehafteten 32-Bit-Platz simuliert, liest sich gespeichertes 2 147 483 648 als −2 147 483 648 zurück, was 1901-12-13T20:45:52Z entspricht. Das Verhalten ist weder Ausnahme noch Absturz: Der Wert wird schlicht zu einem Datum 136 Jahre in der Vergangenheit und wird verwendet. Die Folgen hängen vom Code darüber ab. Sortierungen kehren sich um. Alters- und Dauerberechnungen werden gewaltig negativ. Zertifikate und Sitzungen wirken längst abgelaufen oder nie ablaufend. Cron-artige Planer feuern dauernd oder gar nicht. Datensätze landen in der falschen Partition. Gefährlich ist es genau deshalb, weil nichts einen Fehler auslöst: Jede Schicht bekommt eine wohlgeformte Zahl und verhält sich für diese Zahl korrekt. Deshalb ist Testen auch einfach — setze heute ein Feld auf 2147483648 und lies es zurück, statt auf das Datum zu warten.

Meine Server sind 64-bittig. Bin ich vor dem 2038-Problem sicher?

Dein Betriebssystem ja, deine Anwendung womöglich nicht. Auf einer modernen 64-Bit-Maschine beträgt sizeof(time_t) 8 Byte — hier geprüft — und die Shell gibt für den Wert 2147483648 ohne Überlauf Tue Jan 19 03:14:08 UTC 2038 aus. Doch der Kernel ist selten der Ort der Grenze. Die Angriffsfläche liegt in Feldern, die du gewählt hast: eine INTEGER- oder int32-Datenbankspalte mit Epochensekunden, ein Protokoll oder Dateiformat mit festem 32-Bit-Zeitstempelfeld, eine für ein 32-Bit-Embedded-Ziel kompilierte Struktur, ein vor Jahren geschriebener Binärsatz fester Breite. MySQLs TIMESTAMP-Spaltentyp ist ein dokumentiertes Beispiel: spezifiziert bis 2038-01-19 03:14:07 UTC, unabhängig davon, wie viele Bit der Server hat, während DATETIME nicht betroffen ist. Eine zweite, weniger offensichtliche Fläche sind Fremdgeräte im Bestand — Drucker, Kameras, Steuerungen, Sensoren —, deren Firmware konstruktionsbedingt 32-bittig ist und vielleicht nie aktualisiert wird. Die Prüfung lohnt sich jetzt statt 2037, denn die Ausfälle beginnen bei zukunftsdatierten Werten, und 2026 liegt bereits im Elfeinhalbjahresfenster.

Woran erkenne ich, ob eine Zahl Sekunden oder Millisekunden sind?

Zähle die Stellen. Ein heutiger Zeitstempel hat in Sekunden zehn Stellen und behält sie bis 2286; derselbe Zeitpunkt hat in Millisekunden dreizehn. Für 2026-08-15T00:00:00Z lauten die beiden Werte 1786752000 und 1786752000000. Im Zweifel umwandeln und das Ergebnis ansehen, denn beide Fehler liefern etwas offensichtlich Absurdes: Der Sekundenwert als Millisekunden gelesen ergibt 1970-01-21T16:19:12Z, drei Wochen nach der Epoche, und der Millisekundenwert als Sekunden gelesen ergibt das Jahr 58589. Ein Datum im Januar 1970 oder in ferner Zukunft ist fast immer dieser Fehler und keine schlechten Daten. Die dauerhafte Lösung ist nicht Erkennung, sondern Benennung. Nenne das Feld expiresAtSeconds oder createdAtMillis, damit die Einheit mit dem Wert reist, oder schicke über Dienstgrenzen eine RFC-3339-Zeichenkette wie 2026-08-15T00:00:00Z — selbstbeschreibend, als Text korrekt sortierbar, übersteht das Einfügen in ein Log und kostet rund zwanzig Byte.

Sind meine Dauerberechnungen wegen Schaltsekunden falsch?

Technisch ja, praktisch fast nie in relevantem Ausmaß. Die Subtraktion zweier Unix-Zeitstempel liefert die Zählerdifferenz, die jede dazwischenliegende Schaltsekunde auslässt. Über die Schaltsekunde von 2016 hinweg sagt der Zähler, zwischen 2016-12-31T00:00:00Z und 2017-01-01T00:00:00Z seien 86 400 Sekunden vergangen, während tatsächlich 86 401 SI-Sekunden verstrichen. Da überhaupt nur siebenundzwanzig Schaltsekunden eingefügt wurden, beträgt der größtmögliche Fehler einer Dauer über den gesamten Zeitraum seit 1972 siebenundzwanzig Sekunden — belanglos für Abrechnung, Sitzungsdauer, Cache-Ablauf, Latenz im Millisekundenbereich oder irgendeine betriebliche Messung. Relevant wird es bei Satellitenentfernungsmessung, Hochpräzisionsphysik und Finanzsequenzierung unterhalb der Sekunde, und diese Bereiche nutzen TAI oder GPS-Zeit ganz ohne Schaltsekunden. Es gibt allerdings eine weit größere praktische Gefahr: Dauern mit der Wanduhr zu messen. NTP-Korrekturen, Migrationen virtueller Maschinen und manuelle Umstellungen können eine Wanduhr um weit mehr als eine Sekunde vor- oder zurückbewegen. Nimm zum Messen von Dauern eine monotone Uhr — die deine Sprache etwa als performance.now oder als stetige Uhr anbietet — und behalte Wanduhr-Zeitstempel dafür, festzuhalten, wann etwas geschah.

Sollte ich Zeitstempel in UTC oder mit Zeitzone speichern?

Es hängt davon ab, ob du etwas Geschehenes festhältst oder etwas Künftiges planst. Für alles Vergangene — eine Logzeile, eine Bestellung, eine Zahlung, ein Prüfeintrag — speichere den Zeitpunkt in UTC und wandle erst zur Anzeige um. Der Zeitpunkt ist eine Tatsache und ändert sich nie; wie er in der Ortszeit eines Nutzers erscheint, ist Darstellungssache und jederzeit neu berechenbar. Für alles künftig Geplante ist UTC die falsche Wahl, und genau dieser Fall wird am häufigsten falsch gemacht. Ein Treffen um 09:00 in Berlin im kommenden November ist kein Zeitpunkt, sondern eine Wanduhrzeit in einer Rechtsordnung. Ändert Deutschland bis dahin seine Uhrenregeln, wandert der korrekte Zeitpunkt, und ein heute gespeicherter UTC-Wert würde zu einem Termin zur falschen Ortszeit. Speichere lokales Datum, lokale Uhrzeit und die IANA-Zonenkennung wie Europe/Berlin und löse erst bei Bedarf zu einem Zeitpunkt auf. Regierungen ändern Zonenregeln tatsächlich, meist mit wenigen Wochen Vorlauf, und die tz-Datenbank wird mehrmals jährlich nachgeführt.