Ein Unix-Zeitstempel ist eine einzige Zahl: wie viele Sekunden seit Mitternacht UTC am 1. Januar 1970 vergangen sind. Das ist der ganze Entwurf, und diese Sparsamkeit erklärt, warum er überall steckt — in Logs, Datenbanken, JWTs und APIs. Sie erklärt auch, warum es ein Werkzeug braucht: Eine Zahl wie 1752537600 sagt einem Menschen rein gar nichts.
Sekunden oder Millisekunden: der Faktor 1000
Unix-Zeit zählt Sekunden. JavaScript zählt Millisekunden — Date.now() liefert eine tausendmal größere Zahl, und jeder JavaScript-Date-Konstruktor ebenso. Dieses Missverhältnis verursacht mehr kaputte Zeitstempel als alles andere zusammen.
Das Symptom ist unverkennbar, sobald man es kennt. Gib einen Sekundenwert an etwas, das Millisekunden erwartet, und du landest im Januar 1970: Die gesamte bisherige Unix-Zeit schrumpft auf drei Wochen. Gib Millisekunden, wo Sekunden erwartet werden, und du bekommst ein Datum in fünfzigtausend Jahren. Keines wirft einen Fehler. Beide werden anstandslos als Datum dargestellt — deshalb überlebt der Bug jedes Code-Review.
Ein schneller Test: Ein aktueller Zeitstempel in Sekunden hat zehn Stellen, in Millisekunden dreizehn. Starrst du auf eine Zahl und bist unsicher, zähl die Stellen, bevor du teilst.
Ein Zeitstempel hat keine Zeitzone
Das lohnt sich zu verinnerlichen, denn es löst die meiste Zeitzonenverwirrung auf. Ein Unix-Zeitstempel ist ein Augenblick — derselbe Moment für jeden Lebenden. Er ist nicht mehr in UTC als in Tokioter Zeit; er ist einfach. Zeitzonen kommen erst ins Spiel, wenn du diesen Augenblick als lesbares Datum darstellst, und das ist eine Anzeigeentscheidung, keine Eigenschaft der Daten.
"Diesen Zeitstempel nach UTC umrechnen" ist also gar keine Umrechnung — es ist eine Formatierungsentscheidung. Die Zeitzonenauswahl hier ändert, wie derselbe Augenblick geschrieben wird, nicht was er bedeutet. Deshalb erspart das Speichern von Zeitstempeln statt lokaler Datumszeichenketten so viel Schmerz: Ein Augenblick ist eindeutig, "2025-10-26 02:30" nicht.
Das Jahr-2038-Problem ist real und beißt bereits
Jahrzehntelang speicherten Unix-Systeme Zeit in einer vorzeichenbehafteten 32-Bit-Ganzzahl. Die läuft bei 2147483647 Sekunden aus, also um 03:14:07 UTC am 19. Januar 2038. Eine Sekunde später läuft der Wert über, kippt ins Negative, und das Datum wird der 13. Dezember 1901.
Das klingt fern und ist es nicht. Jedes System, das ein Datum mehr als ein paar Jahre voraus berechnet, überschreitet die Grenze bereits: eine dreißigjährige Hypothek, ein Zertifikatsablauf, eine Rentenprognose. Fehler daraus wurden lange vor 2020 in Produktion gefunden. Die meisten modernen Plattformen sind auf 64-Bit-Zeit umgestiegen — was die Grenze über die erwartete Lebensdauer der Sonne hinausschiebt — aber eingebettete Geräte, alte Dateiformate und manche Datenbankspalten nicht. Speicherst du heute einen Zeitstempel in einer 32-Bit-Spalte, ist das ein Fehler mit Fälligkeitsdatum.
Unix-Zeit ignoriert Schaltsekunden mit Absicht
Eine Tatsache, die selbst erfahrene Entwickler überrascht: Ein Unix-Zeitstempel ist keine echte Zählung vergangener Sekunden. Seit 1972 wurden weltweit 27 Schaltsekunden eingefügt, um Uhren mit der Erdrotation im Takt zu halten, und Unix-Zeit überspringt jede einzelne. Sie definiert jeden Tag als exakt 86400 Sekunden — ob dieser Tag nun 86400 Sekunden hatte oder nicht.
Der Handel ist beabsichtigt. Er macht die Arithmetik trivial — jedes Datum wird per simpler Division zum Zeitstempel — um den Preis, dass die Zählung im absoluten Sinn leicht falsch ist. Er bedeutet auch, dass die echte Schaltsekunde 23:59:60 schlicht nicht ausdrückbar ist: JavaScript lehnt sie rundweg ab, und Date.parse("2016-12-31T23:59:60Z") liefert NaN, obwohl es diese Sekunde wirklich gab. Brauchst du echte verstrichene Zeit über Schaltsekunden hinweg, ist Unix-Zeit das falsche Instrument; für die übrigen 99,99 % der Software ist dieser Kompromiss genau richtig.
Mehrdeutige und unmögliche Ortszeiten
Zeitstempel sind sauber; Ortszeiten nicht. Zweimal im Jahr bringt die Sommerzeit die Wanduhr aus dem Tritt. Wenn in Rom am letzten Sonntag im Oktober die Uhren zurückgestellt werden, passiert 02:30 zweimal — eine Ortszeit "2025-10-26 02:30" bezeichnet zwei verschiedene Augenblicke, und nichts in der Zeichenkette verrät welchen. Wenn die Uhren im März vorspringen, existiert 02:30 überhaupt nicht.
Deshalb ist die Umwandlung einer Ortszeit in einen Zeitstempel wirklich verlustbehaftet, während der umgekehrte Weg es nie ist. Speicherst du Termine, Logeinträge, irgendetwas, wo der exakte Augenblick zählt, speichere den Zeitstempel und stelle die Ortszeit erst bei der Ausgabe dar — nicht umgekehrt.
Häufige Fragen
Werden meine Daten an einen Server geschickt?
Nein. Dieses Tool ist als "client" gekennzeichnet: Die Umrechnung ist Arithmetik und Formatierung in deinem Browser-Tab, mit dessen eigener Zeitzonendatenbank. Es wird nichts übertragen.
Mein Zeitstempel zeigt 1970. Was ist schiefgelaufen?
Etwas hat Sekunden als Millisekunden gelesen. Multipliziere mit 1000 und das Datum ergibt Sinn. Meist bedeutet es, dass ein in der Datenbank korrekter Wert ohne Umrechnung direkt an einen JavaScript-Date-Konstruktor gereicht wurde — Date erwartet Millisekunden und warnt dich nicht.
Kann ein Zeitstempel negativ sein?
Ja — das heißt nur "vor 1970". Ein Zeitstempel von -1 ist der 31. Dezember 1969 um 23:59:59 UTC. Die meiste Software geht damit richtig um, aber nicht alle: Geburtsdatumsfelder für vor 1970 Geborene waren historisch eine reiche Fehlerquelle in Systemen, deren Autoren Zeitstempel für immer positiv hielten.
Warum zeigt derselbe Zeitstempel auf dem Bildschirm meines Kollegen eine andere Uhrzeit?
Weil ihr in verschiedenen Zeitzonen seid — korrektes Verhalten, kein Fehler. Der Augenblick ist identisch, nur seine Darstellung unterscheidet sich. Sollen alle dieselbe Uhrzeit ablesen — etwa ein geplantes Wartungsfenster — nenne die Zeitzone ausdrücklich daneben, oder nimm UTC und sag es dazu.
Soll ich Daten als Zeitstempel oder als Zeichenketten speichern?
Speichere den Augenblick, sei es als Ganzzahl-Zeitstempel oder als richtige Zeitstempel-mit-Zeitzone-Spalte — deine Datenbank hat mit ziemlicher Sicherheit eine, und sie beherrscht Bereiche und Arithmetik, die eine nackte Ganzzahl nicht kann. Zu vermeiden ist eine lokale Datumszeichenkette ohne Zone: Sie ist zweimal im Jahr an den Sommerzeitgrenzen mehrdeutig, und die fehlende Information lässt sich später nicht wiederherstellen.