Was ist ein Unix-Zeitstempel?

Ein Unix-Zeitstempel ist eine einzelne Zahl: die Anzahl der Sekunden, die seit der Unix-Epoche vergangen sind, definiert als 00:00:00 UTC am 1. Januar 1970. Das ist alles. Keine Zeitzone, kein Datumsstring, keine Monatsnamen – nur eine ganze Zahl, die jede Sekunde um eins hochzählt.

Da die Epoche fest und universell ist, bedeutet ein Zeitstempel wie 1700000000 exakt denselben Moment überall auf der Erde. Ein Server in Tokio und ein Laptop in Chicago stimmen darin überein, dass er sich auf den 14. November 2023 um 22:13:20 UTC bezieht. Die lokale Anzeige unterscheidet sich je nach Zeitzone, aber die zugrundeliegende Zahl tut das nie.

Eine bewusste Vereinfachung: Die Unix-Zeit ignoriert Schaltsekunden. Sie geht davon aus, dass jeder Tag exakt 86.400 Sekunden lang ist, was astronomisch nicht ganz korrekt ist, aber die Arithmetik sauber hält. Mehr dazu weiter unten.

Warum Ingenieure sie lieben

Zeitstempel sind überall in der Software – Dateiänderungszeiten, Datenbankeinträge, API-Antworten, JWT-Ablauffelder, Logzeilen – und das aus gutem Grund:

• Sie sind ein einzelner Wert. Eine ganze Zahl speichert ein vollständiges Datum und eine Uhrzeit. Kein Parsen, keine Unklarheit über MM/TT versus TT/MM.
• Sie sind zeitzonenunabhängig. Die Zahl ist immer UTC. Du konvertierst nur dann in die Ortszeit, wenn du sie einem Menschen anzeigst.
• Sie lassen sich trivial vergleichen und sortieren. Welches Ereignis war zuerst? Die kleinere ganze Zahl. Dauer zwischen zwei Ereignissen? Subtrahiere sie; das Ergebnis ist in Sekunden.
• Sie lassen sich kompakt speichern. Ein einzelner 4- oder 8-Byte-Integer im Vergleich zu einem formatierten String.

Deshalb arbeitet so viel Infrastruktur intern mit Epochensekunden, selbst wenn die Schnittstelle dir ein freundliches 2026-07-23 anzeigt. Wenn du zwischen den beiden Darstellungen wechseln möchtest, erledigt ein Unix-Zeitstempel-Konverter die Übersetzung in beide Richtungen.

Einen Zeitstempel lesen: Ein durchgerechnetes Beispiel

Nimm den Zeitstempel 1000000000 – ein berühmter, weil er im Live-Fernsehen unter Unix-Enthusiasten überlief.

Um ihn von Hand zu lesen, teilst du die Sekunden in größere Einheiten auf. Grob gerechnet sind 1.000.000.000 Sekunden etwa 31,7 Jahre (ein Jahr hat ~31.556.952 Sekunden). Addierst du das zur Epoche 1970, landest du im Jahr 2001. Der genaue Moment ist der 09. September 2001, 01:46:40 UTC.

Du führst diese Arithmetik selten manuell durch – jede Sprache hat eine eingebaute Funktion. In Python:

```python from datetime import datetime, timezone datetime.fromtimestamp(1000000000, tz=timezone.utc)

2001-09-09 01:46:40+00:00

```

Der entscheidende Punkt: Die Konvertierung ist immer an UTC verankert. Die Funktion wandelt eine rohe Sekundenzahl in ein Kalenderdatum um, indem sie von der Epoche aus vorwärts geht. Wenn du stattdessen die Ortszeit haben möchtest, wendest du einen Zeitzonen-Offset nach der UTC-Konvertierung an – der Zeitstempel selbst trägt keine Zoneninformationen.

Das Jahr-2038-Problem

Hier wird die Geschichte interessant – und wo viele ansonsten gut gebaute Systeme eine tickende Uhr in sich tragen.

Jahrzehntelang war der in C verwendete Standardtyp für die Unix-Zeit, time_t, üblicherweise ein vorzeichenbehafteter 32-Bit-Integer. Ein vorzeichenbehafteter 32-Bit-Integer kann Werte von −2.147.483.648 bis 2.147.483.647 darstellen. Diese Obergrenze ist das Problem.

Zählt man die Sekunden ab der Epoche 1970, wird der Wert 2.147.483.647 am 19. Januar 2038 um 03:14:07 UTC erreicht. Eine Sekunde später müsste der Zähler auf 2.147.483.648 steigen – aber diese Zahl passt nicht in einen vorzeichenbehafteten 32-Bit-Integer. Anstatt weiter nach oben zu zählen, läuft der Bitbereich über und wickelt sich auf den negativsten Wert, −2.147.483.648.

Ein negativer Zeitstempel wird als eine Zeit vor der Epoche interpretiert. Die Uhr bleibt also nicht einfach stehen – sie springt zurück zum 13. Dezember 1901. Jedes System, das seinem 32-Bit-time_t vertraute, glaubt plötzlich, es sei das frühe 20. Jahrhundert.

Dies wird oft als Y2K38-Fehler oder Unix-Jahrtausendfehler bezeichnet, und strukturell ist es derselbe Überlauf fester Breite, der die Jahrtausendwende-Angst auslöste – nur weiter in der Zukunft und verwurzelt in binären Integergrenzen anstatt in zweistelligen Jahreszahlen.

Wo es tatsächlich zuschlägt

Moderne 64-Bit-Desktops und -Server wurden vor Jahren weitgehend behoben. Das Risiko konzentriert sich auf Stellen, die schwer zu aktualisieren sind:

• Eingebettete und industrielle Systeme. Router, Steuerungen, medizinische Geräte, Fahrzeug-ECUs und IoT-Hardware, die mit 32-Bit-time_t ausgeliefert wurden und 20+ Jahre unberührt laufen können. Viele heute eingesetzte Geräte werden 2038 noch in Betrieb sein.
• Legacy-C-Code. Anwendungen, die gegen eine alte time_t-Definition kompiliert wurden, insbesondere wenn der Typ in Datenträgerformate oder Netzwerkprotokolle eingedrungen ist.
• Alte Datenbanken und Dateisysteme. Speicherformate, die Zeitstempel in 32-Bit-Felder packten. Einige ältere Systeme zeigen bereits Symptome, wenn sie mit zukünftigen Daten umgehen – denk an eine 20-jährige Hypothek oder ein Zertifikat, dessen Gültigkeit über 2038 hinausreicht.

Die Fehlerart ist nicht immer ein dramatischer Absturz. Manchmal ist es ein subtil falsch berechnetes Datum: ein abgelaufenes Token, das als gültig gelesen wird, eine Sortierreihenfolge, die sich umkehrt, ein geplanter Job, der im Jahr 1901 ausgelöst wird.

Die Lösung: 64-Bit-Zeit

Die Abhilfe ist im Prinzip einfach – time_t auf 64 Bit verbreitern. Ein vorzeichenbehafteter 64-Bit-Integer kann Sekunden weit über jeden praktischen Horizont hinaus zählen: Der Überlaufpunkt liegt etwa 292 Milliarden Jahre in der Zukunft, bequem jenseits der erwarteten Lebensdauer der Sonne.

Die meisten aktuellen Betriebssysteme haben diesen Schritt bereits vollzogen. 64-Bit-Linux verwendet ein 64-Bit-time_t; selbst 32-Bit-Linux hat in den letzten Jahren 64-Bit-Zeitunterstützung im Kernel und in glibc erhalten. Der schwierige Teil ist nicht die Lösung selbst – es ist das Finden und Neukompilieren jedes einzelnen Firmware-Teils, jedes gespeicherten Formats und jeder Drittanbieter-Binärdatei, die immer noch 32 Bit annimmt. Diese Prüfarbeit ist das eigentliche 2038-Projekt.

Wie Schaltsekunden hineinpassen

Die astronomische Zeit und die Atomzeit driften geringfügig auseinander, daher fügt die offizielle UTC gelegentlich eine Schaltsekunde ein, um die Uhren mit der Erdrotation synchron zu halten. Die Unix-Zeit tut so, als ob diese nicht existieren – sie kodiert fest 86.400 Sekunden pro Tag.

Wenn eine Schaltsekunde auftritt, "verschmieren" Systeme sie typischerweise – sie verteilen die zusätzliche Sekunde über ein Fenster (Google hat eine 24-Stunden-Verschmierung populär gemacht), sodass keine Uhr jemals das unmögliche 23:59:60 anzeigen muss. Das Ergebnis: Unix-Zeitstempel bleiben glatt und monoton, auf Kosten einer winzigen Sekundenbruchteil-Abweichung von der strengen UTC während einer Verschmierung. Für praktisch jede Software ist das genau der Kompromiss, den man möchte. Der 2038-Überlauf ist ein Integer-Breiten-Problem; Schaltsekunden sind eine separate, viel kleinere Definitions-Eigenheit – verwechsle sie nicht.

Wichtige Erkenntnisse

• Ein Unix-Zeitstempel sind Sekunden seit dem 1. Januar 1970, 00:00:00 UTC, Schaltsekunden ignoriert.
• Es ist eine einzelne, zeitzonenunabhängige ganze Zahl – einfach zu speichern, zu vergleichen und zu sortieren.
• Die Konvertierung ist immer relativ zu UTC; die Ortszeit wird nachträglich angewendet.
• Der vorzeichenbehaftete 32-Bit-time_t läuft am 19. Januar 2038 um 03:14:07 UTC über, wickelt sich auf einen negativen Wert und springt ins Jahr 1901.
• Die Lösung ist 64-Bit-time_t; die Mühe ist die Prüfung eingebetteter und Legacy-Systeme.

Möchtest du es in Aktion sehen? Füge einen beliebigen Epochenwert in den Unix-Zeitstempel-Konverter ein, um ihn als menschenlesbares Datum zu lesen – oder gehe den umgekehrten Weg und wandle ein Datum in seinen Zeitstempel um.

Häufig gestellte Fragen

Ist ein Unix-Zeitstempel in Sekunden oder Millisekunden?

Die klassische Unix-Zeit ist in Sekunden. JavaScript und viele Web-APIs verwenden jedoch Millisekunden seit der Epoche, daher ist ein Wert wie 1700000000000 1.000× größer. Ein schneller Hinweis: Ein sekundenbasierter Zeitstempel für ein aktuelles Datum hat 10 Ziffern; ein millisekundenbasierter hat 13. Im Zweifelsfall überprüfe die Größenordnung vor der Konvertierung.

Wird das Jahr-2038-Problem mein Telefon oder meinen Laptop zum Absturz bringen?

Fast sicher nicht. Moderne 64-Bit-Betriebssysteme verwenden bereits ein 64-Bit-time_t, das den Überlauf um Milliarden von Jahren verschiebt. Die eigentliche Gefahr liegt in langlebigen eingebetteten Geräten und alter Software, die immer noch auf 32-Bit-Zeit angewiesen ist und möglicherweise vor 2038 nicht aktualisiert wird.

Kann ein Unix-Zeitstempel negativ sein?

Ja. Negative Werte stellen Zeitpunkte vor der Epoche 1970 dar – zum Beispiel ist -1 der 31. Dezember 1969, 23:59:59 UTC. Genau das produziert ein 32-Bit-Überlauf im Jahr 2038, weshalb die Uhr scheinbar ins Jahr 1901 zurückzuspringen scheint.

Warum ignoriert die Unix-Zeit Schaltsekunden?

Um die Mathematik einfach und vorhersagbar zu halten. Wenn jeder Tag als exakt 86.400 Sekunden behandelt wird, sind Dauern einfach Subtraktionen, und Zeitstempel bleiben monoton. Die kleine Abweichung von der astronomischen UTC wird durch "Verschmieren" der Schaltsekunde gehandhabt, was fast alle Anwendungen dem Umgang mit einem 23:59:60-Randfall vorziehen.

Wie konvertiere ich einen Zeitstempel, ohne Code zu schreiben?

Verwende ein Online-Tool. Der Unix-Zeitstempel-Konverter akzeptiert einen Epochenwert und zeigt sofort die passende UTC- und Ortszeit an, und er wandelt auch Kalenderdaten zurück in Zeitstempel um.