Unix-Zeitstempel erklärt: Sekunden, Millisekunden, Zeitzonen und 2038

Öffnen Sie fast jede Protokolldatei, Datenbanktabelle oder API-Antwort und Sie finden Zahlen wie 1760000000. Das ist ein Unix-Zeitstempel: die Anzahl der abgelaufenen Sekunden seit 00:00:00 UTC am 1. Januar 1970, bekannt als die Unix-Ära. Es ist die häufigste Art, wie Computer einen Moment in der Zeit darstellen, und das Verständnis verhindert eine ganze Klasse von Fehlern, die Zeitzonen, Sommerzeit und Datenabschlüsselung betreffen.

Warum zählen Sie Sekunden ab 1970?

Frühe Unix-Entwickler brauchten eine einfache, kompakte Zeitdarstellung. Das Zählen von Sekunden von einem festen jüngsten Datum, das in eine einzige ganze Zahl passt, war leicht zu vergleichen und abzuziehen und vermied die Komplexität von Kalendern. Das Datum 1. Januar 1970 war einfach ein bequemer runder Ausgangspunkt, als Unix gebaut wurde.

Die Vorteile gelten noch heute:

• Zeitzone unabhängig. Ein Zeitstempel kennzeichnet einen Augenblick, nicht eine Wanduhr. Das gleiche Ereignis hat den gleichen Zeitstempel in Tokio, Berlin und São Paulo.
• ** Einfache Arithmetik.** Der Unterschied zwischen zwei Zeitstempeln ist eine Dauer in Sekunden. Das ergibt 86.400 Fortschritte pro Tag.
• Kompakte und sortierbare. Eine ganze Zahl benötigt 8 Bytes und wird chronologisch sortiert.
• Eindeutig. Keine Verwechslung zwischen 03/04 und dem 4. März oder dem 3. April.

Sekunden gegen Millisekunden

Der häufigste Zeitstempelfehler ist das Mischen von Einheiten:

• Unix-Tools, die meisten Datenbanken, JWT und viele APIs verwenden ** Sekunden **: 10 Ziffern heute, wie 1760000000.
• JavaScript's Date.now(), Java's System.currentTimeMillis() und viele Analysesysteme verwenden ** Millisekunden**: 13 Ziffern, wie 1760000000000.
• Einige Systeme verwenden Mikrosekunden (16 Ziffern) oder Nanosekunden (19 Ziffern).

Wenn man Millisekunden als Sekunden interpretiert, ergibt sich ein Datum in Zehntausenden von Jahren in der Zukunft; die Umkehrung bringt einen im Januar 1970. Wenn Sie jemals "1970-01-21" in einer Benutzeroberfläche sehen, hat jemand Sekunden überschritten, wo Millisekunden erwartet wurden. Ein Zeitstempel-Konverter erkennt die Einheit nach Länge, was eine schnelle Geistessicherung ist.

Umwandlung von Zeitstempeln in gemeinsame Sprachen

JavaScript

const nowSeconds = Math.floor(Date.now() / 1000);
const date = new Date(1760000000 * 1000);
date.toISOString(); // "2025-10-09T08:53:20.000Z"

Ich bin ein Python.

import time, datetime
now = int(time.time())
dt = datetime.datetime.fromtimestamp(1760000000, tz=datetime.timezone.utc)

Immer tz= in Python passieren; ohne diese gibt fromtimestamp eine naive Ortszeit zurück, die leicht falsch interpretiert werden kann.

**SQL (PostgreSQL) **

SELECT to_timestamp(1760000000);           -- timestamptz
SELECT extract(epoch FROM now())::bigint;  -- current Unix time

Geht schon.

t := time.Unix(1760000000, 0).UTC()
now := time.Now().Unix()

Schal.

date +%s                    # current timestamp
date -u -d @1760000000      # GNU date
date -u -r 1760000000       # macOS/BSD date

Zeitzonen: speichern UTC, lokal anzeigen

Ein Zeitstempel hat keine Zeitzone, sondern ist ein absoluter Augenblick. Bei der Umwandlung von Daten in und von Daten, die für den Menschen lesbar sind, entstehen Probleme:

• Datum ohne Zone interpretieren. new Date("2026-03-29 02:30") wird in der lokalen Zeitzone der Maschine interpretiert, die den Code ausführt. Auf einem Server in UTC und einem Laptop in Berlin erzeugt er unterschiedliche Zeitstempel.
• Die Sommerzeiten und -überschneidungen. In Zonen mit der Sommerzeit gibt es einige Ortszeiten, die nicht vorhanden sind (Uhren springen nach vorne) und andere kommen zweimal vor (Uhren gehen zurück). Ein Zeitstempel hat keine solche Mehrdeutigkeit.
• Speichern von Ortszeiten. Wenn Sie "2026-11-01 01:30" ohne Zone speichern, können Sie nie sicher sein, welcher Moment es war.

Die Faustregel: Speichern und senden Sie Zeitstempel oder ISO 8601-Strings mit einem expliziten Versatz (2026-10-11T09:30:00Z oder +02:00). Nur bei Anzeige in die lokale Zone des Benutzers konvertieren. Speichern Sie den IANA-Zeitzone-Namen des Benutzers (z. B. Europe/Berlin) separat, wenn Sie Dinge in ihrer lokalen Zeit planen müssen.

ISO 8601 gegen Unix-Zeitstempel

ISO 8601-Strings wie 2026-10-11T09:30:00Z sind für den Menschen lesbar und auch eindeutig, wenn sie Z oder einen Versatz enthalten. Viele APIs bevorzugen sie wegen der Lesbarkeit. Unix Zeitstempel sind kleiner und schneller zu vergleichen. Beide sind in Ordnung; Wichtig ist die Konsistenz und immer auch die Zoneninformation.

Schaltzeiten

Die Erdrotation ist etwas unregelmäßig, so dass die offizielle UTC gelegentlich eine Schaltsekunde einfügt. Unix-Zeit ignoriert sie: Jeder Tag ist genau 86.400 Sekunden, und während einer Schaltsekunde wiederholt sich der Zeitstempel oder wird verschmiert. Bei fast allen Anwendungen ist dies unsichtbar. Wenn Sie mit hocherfülltem Zeitgerät arbeiten, verwenden Sie stattdessen TAI- oder GPS-Zeit. Internationale Zeitmessungseinrichtungen haben beschlossen, bis 2035 die Schaltzeiten auslaufen zu lassen, was dies noch weniger besorgniserregend machen wird.

Das Problem des Jahres 2038

Viele ältere Systeme speichern Unix-Zeit als signierte 32-Bit-Vollzahl, deren maximaler Wert 2.147.483.647 beträgt. Das entspricht 03:14:07 UTC am 19. Januar 2038. Eine Sekunde später überfließt der Wert auf −2.147.483.648, was dem 13. Dezember 1901 entspricht.

Moderne 64-Bit-Betriebssysteme, Sprachen und Datenbanken verwenden 64-Bit-Zeitstempel, die für etwa 292 Milliarden Jahre nicht überlaufen. Die Risiken bestehen weiterhin in:

• Eingebettete Geräte und industrielle Steuerungen mit langer Lebensdauer.
• Dateiformate und Netzwerkprotokolle mit 32-Bit-Zeitfeldern
• Datenbankspalten, die als 32-Bit-INT mit Epochsekunden deklariert sind. Der Typ TIMESTAMP von MySQL hat eine Grenze von 2038; DATETIME oder BIGINT nicht.

Überprüfen Sie jetzt langlebige Daten, vor allem alles, was zukünftige Daten speichert, wie z.B. den Ablauf eines Zertifikats oder 20-Jahresverträge.

Negative Zeitstempel

Dates vor 1970 haben negative Zeitstempel. -86400 ist der 31. Dezember 1969. Die meisten modernen Sprachen behandeln sie korrekt, aber einige ältere APIs und Tabellenkalkulationen nicht, also testen Sie historische Daten explizit.

Praktische Debugging-Checkliste

1. Zählen Sie die Ziffern: 10 für Sekunden, 13 für Millisekunden.
2. Konvertieren Sie zuerst auf UTC, dann auf lokale Zeit, um Unit Bugs von Zone Bugs zu trennen.
3. Überprüfen Sie, ob eine Datenfolge Z oder einen Versatz enthält, bevor Sie sie analysieren.
4. Vergleichen Sie Server- und Client-Uhren, wenn Token oder Signaturen mit Fehlern "ausgelaufen" oder "noch nicht gültig" versagen Siehe [wie JWT funktioniert] (/blog/how-jwt-works) warum exp und nbf Unix-Sekunden sind.
5. Wenn Sie wiederkehrende Aufgaben planen, denken Sie daran, dass cron in der Zone des Servers ausgeführt wird; diese Cron-Beispiele decken die Details ab.

Zusammenfassung

Ein Unix-Zeitstempel ist die Anzahl der Sekunden seit 1970-01-01 UTC. Es ist einfach, zeitzoneunabhängig und leicht zu berechnen. Die meisten Fehler stammen aus der Vermischung von Sekunden und Millisekunden, der Parsierung von Daten ohne Zonen oder der Speicherung lokaler Zeiten. Speichern Sie UTC, konvertieren Sie an den Kanten, verwenden Sie 64-Bit-Vollzahlen, und Sie werden selten wieder an die Zeit denken müssen.