Unix-Zeit ist das Rohrleitungssystem unter fast jedem Zeitstempel, den Sie je berühren: die Spalte created_at in der Datenbank, der Ablauf eines JWT, die Uhrzeit einer Log-Zeile, das Änderungsdatum einer Datei, HTTP-Header. Trotz ihrer Allgegenwart hat sie Eigenheiten, die Entwickler jedes Jahr überraschen — Sekunden vs. Millisekunden, Zeitzonen-Fallen, der drohende Überlauf 2038. Dieser Artikel erklärt, was Unix-Zeit wirklich ist und wie man sicher damit umgeht.

Was sie ist

Unix-Zeit ist die Anzahl der Sekunden seit 00:00:00 UTC am 1. Januar 1970, der Unix-Epoche. Jeder Zeitpunkt wird zu einer einzigen Ganzzahl — ein Zahlenstrahl, verankert in 1970, der nach vorn (positiv) und weniger nützlich nach hinten (negativ) verläuft. Heute liegt Unix-Zeit bei rund 1,78 Milliarden und steigt.

Warum 1970

Unix wurde in den Bell Labs entwickelt, als das Team einen Nullpunkt für seine neuen Zeitfunktionen brauchte. Die naheliegenden Kandidaten — ein historisch bedeutendes Jahr, ein rundes Jahrhundert — brachten Ballast. Pragmatische Wahl: ein rundes jüngstes Datum, 1. Januar 1970, 00:00:00 UTC. An diesem Tag passierte nichts Besonderes. Sein Wert lag darin, nah genug an „jetzt" zu sein, damit Zahlen klein bleiben, und fern genug, damit bestehende Dateien keine negativen Zeitstempel brauchten.

Sekunden oder Millisekunden

Die ursprüngliche Unix-Zeit ist in Sekunden. Jedes POSIX-System — Linux, macOS, Datenbanken, Pythons time.time() auf int gecastet — liefert Sekunden. Aber JavaScript wählte Millisekunden, als Date.now() 1995 spezifiziert wurde, und die meisten modernen APIs (Java, Go-stdlib, ISO-Formate, moderne Datenbanken) zogen nach. Ergebnis: zwei Konventionen nebeneinander. Ein 10-stelliger Zeitstempel ist fast immer in Sekunden, ein 13-stelliger in Millisekunden. Bei Integrationen prüfen, auf welcher Seite das Gegensystem steht — Mischfehler sind leise und erzeugen Daten mit 53 Jahren Abstand.

Zeitzonen und was Unix-Zeit wirklich darstellt

Unix-Zeit ist immer UTC. Sie kennt keine Zeitzonen. Wenn ein Log „erstellt 1712345678" sagt, ist das ein exakter Punkt in globaler Zeit — die Umrechnung in eine lesbare Zeichenkette ist der Schritt, bei dem die Zeitzone dazukommt. Das ist sogar eine Tugend: Server, Nutzer und Datenbanken können denselben Augenblick in ihrer jeweiligen Ortszeit anzeigen, ohne sich je über das Wann zu streiten.

Das Y2038-Problem

Am 19. Januar 2038 um 03:14:07 UTC läuft eine signierte 32-Bit-Ganzzahl mit Unix-Sekunden über. Die nächste Sekunde springt auf eine negative Zahl — interpretiert als 13. Dezember 1901. Jedes System, das Unix-Zeit noch als int32 speichert, sieht Daten durcheinanderkommen. Embedded-Geräte, alte Binärformate und lang laufende C-Programme sind das Hauptrisiko — Ihre Web-App ist fast sicher in Ordnung, weil jede Mainstream-Sprache und -Datenbank längst auf 64 Bit umgestellt ist. Ein 64-Bit-Unix-Zeitstempel läuft erst in ca. 292 Milliarden Jahren über.

Warum sie weiter dominiert

Jedes andere Zeitstempelformat braucht eine Zeitzone, ein Kalendersystem oder einen Parser, um Sinn zu ergeben. Unix-Zeit ist eine einzige Zahl — interpretierbar ohne Kontext, sortierbar ohne Parsing, kompakt im Speicher, billig zu vergleichen. Ihre Nachkommen — ISO 8601 und RFC 3339 für die Anzeige, monotone Uhren für verstrichene Zeit — decken ab, was sie allein nicht kann. Aber für die Frage „in welchem globalen Augenblick ist das passiert" hat die 1970er-Epoche gewonnen — und wird wohl nicht ersetzt.