Warum der 1. Januar 1970?

Die Bell Labs wählten ihn als rundes, jüngeres Datum, als Unix v1 1971 erschien. Frühere Prototypversionen nutzten den 01.01.1971 mit 1/60-Sekunden-Takten; der Überlauf eines 32-Bit-Zählers wäre in rund 2,3 Jahren eingetreten, also wechselte das Team zu ganzen Sekunden und datierte die Epoche auf den 01.01.1970 UTC zurück. Das war praktisch, nicht theologisch.

Werden Schaltsekunden in der Unix-Zeit gezählt?

Nein. POSIX definiert einen Unix-Timestamp als Anzahl der Sekunden seit der Epoche und nimmt dabei genau 86.400 Sekunden pro Tag an, jeden Tag. Die echte UTC hat gelegentlich eine Schaltsekunde eingefügt (zuletzt am 30. Juni 2017). Die meisten Systeme behandeln dies, indem sie den Zähler eine Sekunde lang einfrieren oder die Schaltsekunde über ein längeres Intervall „verschmieren“ (Googles Ansatz). Die Folge: Derselbe Unix-Timestamp kann während einer positiven Schaltsekunde zwei verschiedenen realen Zeitpunkten entsprechen.

Was genau bricht 2038?

Am 19. Januar 2038 um 03:14:07 UTC läuft ein vorzeichenbehafteter 32-Bit-Zähler für Sekunden-seit-Epoche in eine negative Zahl über, die den 13. Dezember 1901 darstellt. Jedes 32-Bit-System, eingebettete Gerät, Dateiformat oder jede Datenbankspalte, die einen signed int32 für die Zeit nutzt, wird kaputtgehen. 64-Bit-Linux ist vor Jahren migriert; die verbleibende Gefährdung liegt in eingebetteten Systemen, Legacy-Dateiformaten (ext2/3-Inode-Timestamps, ZIP-DOS-Timestamps) und SQL-Spalten, die explizit als INT typisiert sind.

Sollte ich Timestamps als Ganzzahlen oder als ISO-8601-Strings speichern?

Ganzzahlen, wenn Sie rechnen und die Speichergröße zählt. ISO-8601-Strings, wenn Menschen die Daten lesen oder Sie die ursprüngliche Zeitzone bewahren müssen. Viele Systeme speichern beides – UTC-Epoche in ms zum Sortieren und Rechnen plus den ursprünglichen, zeitzonenbewussten ISO-String für Audits. Speichern Sie keine Lokalzeit-Epochenwerte; sobald ein Server die Zeitzone wechselt, sind die Daten stillschweigend fehlerhaft.

Was ist der Unterschied zwischen Sekunden, Millisekunden, Mikrosekunden und Nanosekunden?

Reine Skalierung. Date.now() in JavaScript liefert Millisekunden seit der Epoche. Unix-Syscalls wie clock_gettime(CLOCK_REALTIME) liefern typischerweise Nanosekunden. Datenbank-TIMESTAMP-Typen variieren je nach Anbieter – Postgres sind Mikrosekunden, MySQL DATETIME(6) sind Mikrosekunden, SQL Server arbeitet mit 100-ns-Ticks. Dokumentieren Sie die Einheit immer an der API-Grenze.

Ist ein Unix-Timestamp zeitzonenbewusst?

Ja und nein. Der Timestamp selbst ist eine absolute Sekundenzählung ab einem festen UTC-Zeitpunkt und damit eindeutig. Er trägt aber keine Anzeige-Zeitzone – die Rückrechnung in ein Kalenderdatum erfordert eine Zeitzonen-Wahl. Der Timestamp 1700000000 ist überall derselbe physische Moment, wird aber in Tokio als 14. November und in Los Angeles als 13. November dargestellt.

Guide

Unix-Timestamps erklärt: Epoche, Präzision und das Jahr-2038-Problem

Das weltweit verbreitetste Zeitformat ist ein 56 Jahre alter Behelf mit einer 12-Jahre-Zündschnur.

By Buğra SözeriPublished May 31, 2026

Ein Unix-Timestamp ist eine einzelne Ganzzahl, die einen Zeitpunkt fixiert. Es ist das verbreitetste Zeitformat der Informatik – jede Datenbank, jede Logzeile, jedes JWT und jeder HTTP-Cookie stützt sich letztlich darauf. Es steckt aber auch voller Fallen, die sich nicht melden, bis Ihre Daten bereits falsch sind.

Was es genau ist

Ein Unix-Timestamp ist die Anzahl der Sekunden (oder Millisekunden, Mikrosekunden, Nanosekunden – wählen Sie eine Einheit), die seit 1970-01-01T00:00:00 UTCvergangen sind, üblicherweise „die Unix-Epoche“ genannt. Heute ist das eine Zahl im Bereich von 1,7 Milliarden für Sekunden oder 1,7 Billionen für Millisekunden.

Sie können einen Timestamp mit unserem Timestamp-Konverter in ein Kalenderdatum und zurück umrechnen – fügen Sie eine beliebige Ganzzahl ein und sehen Sie das UTC-Datum, Ihr lokales Datum und die relative Zeit.

Warum 1970?

Die Wahl ist nicht tiefgründig. Die Bell Labs lieferten Unix v1 1971 aus und brauchten ein beliebiges, jüngeres Datum für den Zeitzähler. Ein früherer Prototyp zählte 1/60-Sekunden- Takte seit dem 01.01.1971, doch der 32-Bit-Zähler wäre in knapp 2,5 Jahren übergelaufen. Das Team wechselte zu ganzen Sekunden und datierte die Epoche auf den 01.01.1970 zurück, sodass Daten aus früheren Jahren als negative Zahlen darstellbar waren. Es blieb dabei, weil jedes nachgelagerte System es festschrieb.

Präzision: Sekunden, ms, μs, ns

Verschiedene Schichten des Stacks nutzen verschiedene Einheiten:

Sekunden — das klassische Unix- time(), JWT-Claims iat/exp, HTTP-Date-Header, die meisten Tabellenkalkulations-Exporte.
Millisekunden — JavaScript Date.now(), Java System.currentTimeMillis(), Kafka-Record-Timestamps, MongoDB ObjectId (die ersten 4 Bytes sind Sekunden-seit-Epoche, gepackt neben anderen Feldern in BSON).
Mikrosekunden — Postgres TIMESTAMP, MySQL DATETIME(6), Tracing-Bibliotheken (Jaeger, OpenTelemetry).
Nanosekunden — Linux clock_gettime(CLOCK_REALTIME), Go time.Now().UnixNano(), etcd, neuere OpenTelemetry-Exporter.

An einer API-Grenze niemals raten. 1700000000 ist November 2023, wenn als Sekunden gelesen, oder Januar 1970 plus 20 Tage, wenn als Millisekunden gelesen. Eine schnelle Faustregel: Hat die Ganzzahl rund 10 Stellen, sind es Sekunden; 13 Stellen Millisekunden; 16 Stellen Mikrosekunden; 19 Stellen Nanosekunden. Unser Timestamp-Tool erkennt alle vier automatisch.

Schaltsekunden: die Lüge ganz unten

POSIX definiert einen Unix-Timestamp als „Sekunden seit der Epoche“ und nimmt dabei ausdrücklich an, jeder Tag habe 86.400 Sekunden. Die echte UTC tut das nicht. Seit 1972 wurden 27 positive Schaltsekunden eingefügt, um die UTC mit der Erdrotation in Einklang zu halten. Die jüngste war am 30. Juni 2017.

Striktes POSIX-Verhalten besteht darin, die Uhr während einer Schaltsekunde einzufrieren: Der Timestamp 1483228827 wird zwei Sekunden hintereinander ausgeliefert. Das bricht die Monotonie und lässt alles abstürzen, was annimmt, Timestamps seien eindeutig. Googles Alternative, das „Leap Smearing“, verteilt die zusätzliche Sekunde über ein 24-Stunden-Fenster, sodass keine einzelne Sekunde doppelt vorkommt; AWS, Meta und Microsoft handhaben es inzwischen genauso. Zwei Server mit unterschiedlichen Verfahren können sich rund um ein Schaltereignis um bis zu eine halbe Sekunde unterscheiden.

Für 99 % der Anwendungen spielt das keine Rolle. Für alles, was Ereignisse mit Subsekunden-Präzision über mehrere Anbieter hinweg ordnet, spielt es definitiv eine Rolle.

Das Jahr-2038-Problem

Eine vorzeichenbehaftete 32-Bit-Ganzzahl kann Werte von −2.147.483.648 bis +2.147.483.647 aufnehmen. Als Sekunden seit dem 01.01.1970 UTC interpretiert, ist die Obergrenze 2038-01-19T03:14:07Z. Eine Sekunde später springt der Zähler auf den negativsten Wert, der den 13. Dezember 1901 darstellt.

Moderne 64-Bit-Betriebssysteme nutzen bereits 64-Bit- time_t, das erst in weiteren 292 Milliarden Jahren überläuft. Die verbleibende Gefährdung:

Eingebettete Geräte — Steuergeräte in Fahrzeugen, industrielle SPS, medizinische Implantate. Viele nutzen weiterhin 32-Bit-Zeit und werden nicht aktualisiert.
Dateiformate — ext2/ext3-Inode-Timestamps, das klassische ZIP (DOS-Format), ältere erweiterte NTFS-Attribute.
SQL-Spalten — eine Spalte, die als INT deklariert wurde, um für Epochen-Sekunden „Platz zu sparen“. Prüfen Sie Ihre Schemata jetzt, nicht erst 2037.
Legacy-C-Code, der gegen eine alte libc auf 32-Bit-ARM kompiliert wurde. Die Migration auf 64-Bit-time_t ist ein ABI-Bruch, und viele Anbieter haben sie nicht ausgeliefert.

Eine ausführlichere Behandlung finden Sie in unserem Glossareintrag zum Unix-Timestamp.

Unix-Zeit vs. ISO 8601

ISO 8601 (und sein Internet-Profil, RFC 3339) schreibt die Zeit als 2026-05-31T14:30:00Z. Sie ist für Menschen lesbar, zeitzonenbewusst und selbstbeschreibend. Die Unix-Zeit ist kompakt, als Ganzzahl sortierbar und über den tatsächlichen Zeitpunkt eindeutig – sagt aber nichts darüber, welche Zeitzone der Schreiber zur Anzeige beabsichtigte.

Verwenden Sie ISO 8601 in APIs, Logs und überall, wo ein Mensch den Wert liest. Verwenden Sie Unix-Ganzzahlen zur Speicherung, wenn Platz und Rechnen zählen oder das Sortieren günstig sein muss. Viele Systeme tragen beides – die Ganzzahl für Operationen, den String für Audit-Trails. Den vollen Aufbau finden Sie im Glossareintrag zu ISO 8601.

Häufige Stolperfallen

Zeitzonen-naives Parsen

new Date("2026-05-31") wird in JavaScript als UTC-Mitternacht geparst, aber new Date("2026-05-31 14:00") (beachten Sie das Leerzeichen, kein T) wird in den meisten Engines als Lokalzeit geparst. Die resultierenden Unix-Timestamps unterscheiden sich um Ihren Versatz. Fügen Sie bei Eingaben, die Sie nicht vollständig kontrollieren, immer den Zeitzonen-Bezeichner hinzu (Z, +09:00).

Einheiten stillschweigend mischen

Ein Microservice, der Millisekunden ausgibt, spricht mit einem nachgelagerten Dienst, der Sekunden erwartet. Der nachgelagerte Dienst sieht Timestamps im Jahr 55000 und schreibt sie stillschweigend in die Datenbank. Validieren Sie die Größenordnung eingehender Timestamps immer gegen einen plausiblen Bereich.

Lokalzeit-Epochen

Einige Legacy-Systeme berechnen „Sekunden seit dem 01.01.1970 Lokalzeit“. Das ist keine Unix-Zeit und bricht in dem Moment, in dem ein Server verschoben wird oder die Sommerzeit umspringt. Wenn Sie ein solches System erben, erfassen Sie den Versatz neben der Ganzzahl und konvertieren Sie an der Grenze in eine echte UTC-Epoche.

Probieren Sie den Konverter

Fügen Sie eine beliebige Ganzzahl in unseren Timestamp-Konverter ein, um die UTC- und lokalen Interpretationen nebeneinander zu sehen, mit automatischer Erkennung von Sekunden/ms/μs/ns. Für Stapel-Konvertierung oder zusätzliche Präzisionssteuerung handhabt das Datetime-Timestamp-Tool beide Richtungen.

Fazit

Die Unix-Zeit ist ein großartiger Standard, weil sie kompakt, sortierbar und über den Zeitpunkt eindeutig ist. Sie ist ein furchtbarer Standard in dem Moment, in dem Sie vergessen, in welcher Einheit Sie sich befinden, welche Zeitzone Sie anzeigen wollen oder ob Ihre Speicherung 32-Bit ist. Die Epoche war 1970 eine pragmatische Wahl; die Jahr-2038-Klippe ist die fällig werdende Rechnung. Prüfen Sie Ihre Ganzzahl-Spalten, dokumentieren Sie Ihre Einheiten, und speichern Sie keine Lokalzeit-Epochen.

Frequently asked questions

Warum der 1. Januar 1970?: Die Bell Labs wählten ihn als rundes, jüngeres Datum, als Unix v1 1971 erschien. Frühere Prototypversionen nutzten den 01.01.1971 mit 1/60-Sekunden-Takten; der Überlauf eines 32-Bit-Zählers wäre in rund 2,3 Jahren eingetreten, also wechselte das Team zu ganzen Sekunden und datierte die Epoche auf den 01.01.1970 UTC zurück. Das war praktisch, nicht theologisch.
Werden Schaltsekunden in der Unix-Zeit gezählt?: Nein. POSIX definiert einen Unix-Timestamp als Anzahl der Sekunden seit der Epoche und nimmt dabei genau 86.400 Sekunden pro Tag an, jeden Tag. Die echte UTC hat gelegentlich eine Schaltsekunde eingefügt (zuletzt am 30. Juni 2017). Die meisten Systeme behandeln dies, indem sie den Zähler eine Sekunde lang einfrieren oder die Schaltsekunde über ein längeres Intervall „verschmieren“ (Googles Ansatz). Die Folge: Derselbe Unix-Timestamp kann während einer positiven Schaltsekunde zwei verschiedenen realen Zeitpunkten entsprechen.
Was genau bricht 2038?: Am 19. Januar 2038 um 03:14:07 UTC läuft ein vorzeichenbehafteter 32-Bit-Zähler für Sekunden-seit-Epoche in eine negative Zahl über, die den 13. Dezember 1901 darstellt. Jedes 32-Bit-System, eingebettete Gerät, Dateiformat oder jede Datenbankspalte, die einen signed int32 für die Zeit nutzt, wird kaputtgehen. 64-Bit-Linux ist vor Jahren migriert; die verbleibende Gefährdung liegt in eingebetteten Systemen, Legacy-Dateiformaten (ext2/3-Inode-Timestamps, ZIP-DOS-Timestamps) und SQL-Spalten, die explizit als INT typisiert sind.
Sollte ich Timestamps als Ganzzahlen oder als ISO-8601-Strings speichern?: Ganzzahlen, wenn Sie rechnen und die Speichergröße zählt. ISO-8601-Strings, wenn Menschen die Daten lesen oder Sie die ursprüngliche Zeitzone bewahren müssen. Viele Systeme speichern beides – UTC-Epoche in ms zum Sortieren und Rechnen plus den ursprünglichen, zeitzonenbewussten ISO-String für Audits. Speichern Sie keine Lokalzeit-Epochenwerte; sobald ein Server die Zeitzone wechselt, sind die Daten stillschweigend fehlerhaft.
Was ist der Unterschied zwischen Sekunden, Millisekunden, Mikrosekunden und Nanosekunden?: Reine Skalierung. Date.now() in JavaScript liefert Millisekunden seit der Epoche. Unix-Syscalls wie clock_gettime(CLOCK_REALTIME) liefern typischerweise Nanosekunden. Datenbank-TIMESTAMP-Typen variieren je nach Anbieter – Postgres sind Mikrosekunden, MySQL DATETIME(6) sind Mikrosekunden, SQL Server arbeitet mit 100-ns-Ticks. Dokumentieren Sie die Einheit immer an der API-Grenze.
Ist ein Unix-Timestamp zeitzonenbewusst?: Ja und nein. Der Timestamp selbst ist eine absolute Sekundenzählung ab einem festen UTC-Zeitpunkt und damit eindeutig. Er trägt aber keine Anzeige-Zeitzone – die Rückrechnung in ein Kalenderdatum erfordert eine Zeitzonen-Wahl. Der Timestamp 1700000000 ist überall derselbe physische Moment, wird aber in Tokio als 14. November und in Los Angeles als 13. November dargestellt.

Sources & references

Authoritative references cited by this piece. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.

POSIX.1-2017 (IEEE Std 1003.1) — Seconds Since the Epoch — Kanonische Definition der Unix-Zeit, inklusive der ausdrücklichen Regel von 86.400 Sekunden pro Tag, die Schaltsekunden ausschließt(as of 2026-05-31)
RFC 3339 — Date and Time on the Internet: Timestamps — Das weit verbreitete Internet-Profil von ISO 8601, inklusive „Z“ für UTC(as of 2026-05-31)
IANA Time Zone Database (tzdata) — Referenzdaten, die jedes wohlerzogene System nutzt, das Unix-Timestamps in lokale Kalenderdaten umrechnet(as of 2026-05-31)
Linux kernel — Y2038 status page — Verfolgung der verbleibenden 32-Bit-time_t-Gefährdung im Kernel und in unterstützten Architekturen(as of 2026-05-31)
Google SRE — Leap seconds and smearing — Referenzimplementierung des Schaltsekunden-Smearing-Ansatzes, der inzwischen von AWS, Meta und Microsoft übernommen wurde(as of 2026-05-31)

Published May 31, 2026