Unix-Zeitstempel erklärt
Ein Unix-Zeitstempel ist eine einzelne Zahl für einen Zeitpunkt. Er lässt sich leicht speichern und vergleichen, doch Einheiten, Zeitzonen und Textformate verursachen viele Fehler bei der Umrechnung.
Was Unix-Zeit ist
Die Unix-Zeit (auch Epoch-Zeit oder POSIX-Zeit genannt) zählt die Sekunden seit 1970-01-01 00:00:00 UTC, der Unix-Epoche. 0 ist die Epoche selbst, 1700000000 entspricht 2023-11-14 22:13:20 UTC, und negative Werte sind Zeitpunkte vor 1970: -1 ist 1969-12-31 23:59:59 UTC.
Die Zahl enthält keine Zeitzone: Sie beschreibt überall denselben Zeitpunkt, was sie praktisch zum Speichern, Sortieren und Vergleichen von Ereignissen macht.
Die Unix-Zeit ignoriert Schaltsekunden: Jeder Tag hat genau 86.400 Sekunden. Wird UTC eine Schaltsekunde hinzugefügt, wiederholen Systeme eine Sekunde oder verteilen sie über einen längeren Zeitraum („Smearing“). Eine Differenz über eine Schaltsekunde hinweg ist daher eine Sekunde kürzer als die physikalisch vergangene Zeit.
Sekunden, Millisekunden, Mikrosekunden oder Nanosekunden?
Viele Systeme zählen in kleineren Einheiten, und der Zahl sieht man nicht an, in welcher. Derselbe Zeitpunkt kann als vier sehr unterschiedliche Zahlen auftauchen:
| Einheit | 2023-11-14 22:13:20 UTC | Stellen (2001–2286) | Typische Quellen |
|---|---|---|---|
| Sekunden | 1700000000 |
10 | date +%s, viele APIs, JWT-Claims exp |
| Millisekunden | 1700000000000 |
13 | Date.now() in JavaScript, System.currentTimeMillis() in Java |
| Mikrosekunden | 1700000000000000 |
16 | Manche Datenbanken und Logging-Systeme |
| Nanosekunden | 1700000000000000000 |
19 | UnixNano() in Go, time.time_ns() in Python |
Die Stellen zu zählen ist bei aktuellen Datumsangaben die schnellste Prüfung. Der LeedyBox-Konverter nutzt dieselbe Idee: Werte bis 1011 werden als Sekunden gelesen, bis 1014 als Millisekunden, bis 1017 als Mikrosekunden und größere Werte als Nanosekunden. Diese Faustregel versagt bei Daten, die weit von heute entfernt liegen. Prüfen Sie daher die Einheit, wenn ein Ergebnis seltsam aussieht.
Auch die Genauigkeit spielt eine Rolle. JavaScript-Zahlen stellen ganze Zahlen nur bis 253 (etwa 9 × 1015) exakt dar, daher verliert ein Nanosekundenwert wie 1700000000123456789 seine letzten Stellen, wenn er als normale Zahl geparst wird. Behalten Sie solche Werte als Strings oder verwenden Sie BigInt; der Konverter macht das intern. Um den Claim exp eines Tokens zu lesen, dekodieren Sie das Token mit dem Tool Base64 / URL / JWT.
Zeitzonen und Sommerzeit
Um einen Zeitstempel als Datum und Uhrzeit anzuzeigen, brauchen Sie eine Zeitzone. UTC ist die Referenz; die Ortszeit fügt einen Versatz hinzu, etwa +09:00 in Seoul oder −05:00 in New York im Winter.
Verwenden Sie lieber IANA-Zeitzonennamen wie Asia/Seoul oder America/New_York als feste Versätze und Abkürzungen: Ein Name trägt die Geschichte und die Sommerzeitregeln der Zone in sich, während eine Abkürzung wie CST für mehrere Zonen steht. Die Regeln stammen aus der Zeitzonendatenbank, die sich mehrmals im Jahr ändert, und Browser, Betriebssysteme und Programmiersprachen liefern jeweils eigene Kopien mit. Ergebnisse für vergangene oder zukünftige Daten können sich daher unterscheiden.
Die Sommerzeit erzeugt zwei heikle Fälle, wenn Sie eine Ortszeit in einen Zeitstempel umrechnen:
- Lücke: Wenn die Uhren vorgestellt werden, gibt es manche Ortszeiten nicht. In
America/New_Yorkwird 2026-03-08 02:30 übersprungen, weil die Uhren von 02:00 auf 03:00 springen. - Überlappung: Wenn die Uhren zurückgestellt werden, kommen manche Ortszeiten zweimal vor. 2026-11-01 01:30 tritt einmal in EDT (UTC−04:00) auf und eine Stunde später erneut in EST (UTC−05:00).
Bibliotheken lösen diese Fälle unterschiedlich auf. Der LeedyBox-Konverter verwendet in einer Lücke die spätere gültige Zeit (hier 03:30) und in einer Überlappung das frühere Auftreten und erklärt das in einem Hinweis. Geplante Jobs haben dasselbe Problem; siehe Cron-Ausdrücke lesen.
ISO 8601, RFC 3339 und HTTP-Datumsangaben
Wenn ein Zeitpunkt lesbar sein muss, schreiben Sie ihn in ISO 8601 oder dessen strengerem Internetprofil RFC 3339:
2023-11-14T22:13:20Z
2023-11-15T07:13:20+09:00
2023-11-14T22:13:20.500Z
Z steht für UTC. Mit Z oder einem Versatz ist der String eindeutig. Ein String ohne beides, etwa 2023-11-14T22:13:20, ist eine Ortszeit in einer unbekannten Zone, und Parser lesen ihn unterschiedlich.
HTTP-Header wie Last-Modified und Expires verwenden ein älteres Format, das vom E-Mail-Datumsformat abgeleitet ist (RFC 2822, heute RFC 5322), und zwar in GMT: Tue, 14 Nov 2023 22:13:20 GMT.
Das Jahr-2038-Problem
Viele ältere Systeme speichern die Unix-Zeit in einer vorzeichenbehafteten 32-Bit-Ganzzahl. Deren größter Wert, 2147483647, entspricht 2038-01-19 03:14:07 UTC. Eine Sekunde später läuft der Zähler über auf -2147483648, was als 1901-12-13 20:45:52 UTC gelesen wird. Aktuelle Betriebssysteme und Programmiersprachen verwenden meist 64-Bit-Zeitwerte, die Hunderte Milliarden Jahre abdecken, doch 32-Bit-Felder finden sich weiterhin in eingebetteten Geräten, Dateiformaten, Datenbankspalten und Netzwerkprotokollen. Speichert Ihr Code oder Ihre Datenbank Sekunden in 32 Bit, planen Sie die Umstellung früh und testen Sie Daten nach 2038 schon jetzt.
Zeitstempel in Code und Datenbanken
JavaScript arbeitet in Millisekunden:
Math.floor(Date.now() / 1000); // aktuelle Unix-Zeit in Sekunden
new Date(1700000000 * 1000).toISOString(); // "2023-11-14T22:13:20.000Z"
Date.parse("2026-10-03T09:00:00+09:00") / 1000; // 1790985600
Pythons time.time() gibt Sekunden als Float zurück. Übergeben Sie tz=timezone.utc, sonst liefert fromtimestamp() die Ortszeit des Computers ohne Zone:
import time
from datetime import datetime, timezone
int(time.time()) # Sekunden
datetime.fromtimestamp(1700000000, tz=timezone.utc) # 2023-11-14 22:13:20+00:00
datetime.fromisoformat("2026-10-03T09:00:00+09:00").timestamp() # 1790985600.0
In SQL unterscheiden sich die Funktionen je nach Datenbank:
-- PostgreSQL
SELECT extract(epoch FROM now()); -- Sekunden, mit Nachkommastellen
SELECT to_timestamp(1700000000); -- timestamp with time zone
-- MySQL
SELECT UNIX_TIMESTAMP();
SELECT FROM_UNIXTIME(1700000000); -- in der Zeitzone der Sitzung
Beim Speichern verhindern ein paar Gewohnheiten die meisten Probleme:
- Speichern Sie Zeitpunkte, die bereits stattgefunden haben, in UTC, entweder in einer Spalte vom Typ „timestamp with time zone“ oder als 64-Bit-Ganzzahl, deren Einheit Teil des Spaltennamens ist, etwa
created_at_ms. - Speichern Sie künftige lokale Termine, etwa eine Besprechung um 09:00 Uhr in Seoul, als lokales Datum mit Uhrzeit plus IANA-Zonennamen und berechnen Sie den Zeitstempel bei Bedarf. So verschiebt eine spätere Regeländerung die Besprechung nicht.
- Mischen Sie keine Einheiten in einer Spalte; eine falsche Einheit liegt um den Faktor 1000 oder mehr daneben.
Häufige Fragen
Warum wird mein Zeitstempel in ein Datum im Jahr 1970 umgerechnet?
Der Wert wurde wahrscheinlich in der falschen Einheit gelesen: Als Millisekunden gelesene Sekunden landen im Januar 1970, und als Sekunden gelesene Millisekunden landen Zehntausende Jahre in der Zukunft. Zählen Sie die Stellen oder wählen Sie die Einheit im Konverter.
Hängt ein Unix-Zeitstempel von meiner Zeitzone ab?
Nein. Er zählt Sekunden ab einem festen Zeitpunkt in UTC. Nur das dafür angezeigte Datum und die Uhrzeit hängen von der Zeitzone ab.
Kann die Unix-Zeit eine Schaltsekunde darstellen?
Nein. Die Unix-Zeit behandelt jeden Tag als 86.400 Sekunden, daher hat eine UTC-Zeit wie 23:59:60 keinen eigenen Zeitstempel.