Unix-Timestamp-Konvertierung erklärt — Epoch-Sekunden, Millisekunden und ISO 8601

Jedes System, das einen Zeitpunkt speichert, stellt früher oder später dieselbe Frage: Ist diese Zahl in Sekunden oder Millisekunden? Unix-Timestamps wirken trivial — eine Ganzzahl, die die Sekunden seit dem 1. Januar 1970 zählt — und genau deshalb werden sie falsch behandelt. Ein Wert, der um den Faktor 1000 danebenliegt, ein Datum im Jahr 1970, ein Zeitzonenfehler, der nur bei Nutzern in einer anderen Hemisphäre auftaucht: Sie alle entstehen aus denselben wenigen Missverständnissen.

Dieser Beitrag erklärt, was ein Unix-Timestamp tatsächlich misst, wie sich Sekunden und Millisekunden unterscheiden, wie ISO 8601 hineinpasst und wie man zwischen Formaten konvertiert, ohne zu raten.

Was ein Unix-Timestamp tatsächlich ist

Ein Unix-Timestamp — auch Epoch-Zeit genannt — ist die Anzahl der Sekunden, die seit dem 00:00:00 UTC am 1. Januar 1970, der Unix-Epoche, vergangen sind. Es ist eine schlichte Ganzzahl ohne Zeitzonen-Information: dieselbe Zahl beschreibt denselben Augenblick auf der ganzen Welt.

Weil er keine Zeitzone trägt, ist der Epoch ein natürliches Austauschformat für Maschinen. APIs, Logs, Datenbanken und Message-Queues speichern Timestamps; Menschen lesen Datumswerte. Die Konvertierung zwischen beiden ist der Ort, an dem die Fehler leben.

Beachten Sie, was ein Timestamp nicht enthält: eine Zeitzone, eine Locale oder einen Kalender. 1758537600 ist ein Augenblick. Ob jemand in Berlin oder Bangkok 14:00 oder 21:00 sieht, hängt allein davon ab, wie Sie ihn darstellen.

Sekunden vs. Millisekunden: der häufigste Fehler

Zwei Konventionen bestehen nebeneinander, und beide sind überall zu finden:

• Sekunden — heute 10 Stellen, zum Beispiel 1758537600. Traditionelles Unix, Go's Unix(), Javas getEpochSecond(), Redis und die meisten Datenbanken verwenden diesen Wert.
• Millisekunden — 13 Stellen, zum Beispiel 1758537600000. JavaScripts Date.now(), Javas getTime() und die meisten Browser-APIs verwenden diesen Wert.

Verwechseln Sie die Einheiten, und das Datum springt ins Jahr 1970 oder 2286. Es gibt keine universelle Regel zur Erkennung der Einheit, deshalb ist der zuverlässige Weg, den Vertrag Ihrer Quelle zu kennen. Wenn Sie raten müssen, sind 10 Stellen meist Sekunden und 13 Stellen meist Millisekunden — aber Raten ist der Fehler, nicht die Lösung.

Regel: Speichern Sie die Einheit direkt beim Wert. Nutzen Sie einen Spaltennamen (created_at_ms), ein explizites API-Feld oder eine unit-Eigenschaft. Alles ist besser als eine nackte Ganzzahl namens time.

ISO 8601: die menschenlesbare Seite

ISO-8601-Strings sind das Gegenstück zu Epoch-Zahlen: lesbar, in UTC sortierbar und eindeutig, wenn ein Offselt enthalten ist.

2026-09-22T14:00:00Z       # UTC, angezeigt durch das angehängte Z
2026-09-22T14:00:00+02:00  # derselbe Augenblick, Berliner Ortszeit
2026-09-22T14:00:00.123Z   # Millisekunden bleiben erhalten

Das angehängte Z und der numerische Offset sind keine Dekoration. Ohne eines von beiden hat der String keine Zeitzone, und Ihr Code muss raten — und genau so wird „dieselbe Zeit" leise zu einem Dreistunden-Fehler.

Zeitzonen und UTC

Speichern Sie und vergleichen Sie in UTC, und konvertieren Sie erst an der Kante in eine lokale Zone, wenn Sie für einen Menschen darstellen.

const now = Date.now();                 // Millisekunden seit Epoch
const seconds = Math.floor(now / 1000); // Sekunden seit Epoch
new Date(seconds * 1000).toISOString(); // "2026-09-22T14:00:00.000Z"

Zwei Regeln verhindern die meisten Zeitzonen-Probleme:

• Vergleichen Sie nie eine naive lokale Zeit mit einer anderen. Serialisieren Sie beide zuerst zu Augenblicken und vergleichen Sie dann.
• Halten Sie den Offselt beim Wert, wenn die Zone des Nutzers zählt (Termine, Zeitpläne, Abrechnungszeiträume). Ein UTC-Augenblick plus IANA-Zonen-ID wie Europe/Berlin ist besser als ein fester Offselt, weil feste Offselt mit der Sommerzeit wechseln.

Konvertierungs-Spickzettel

Konvertieren	JavaScript	Python
Millisekunden in einen Datumsstring	new Date(1758537600000).toISOString()	datetime.fromtimestamp(1758537600, tz=timezone.utc)
Datumsstring in Sekunden	Math.floor(Date.parse(s) / 1000)	int(dt.replace(tzinfo=timezone.utc).timestamp())
Sekunden in Millisekunden	seconds * 1000	seconds * 1000
Aktuelle Zeit	Date.now() (Millisekunden)	int(time.time()) (Sekunden)

Beachten Sie, dass Date.now() Millisekunden zurückgibt, während time.time() Sekunden liefert — eine kompakte Illustration dafür, dass die Einheit eine Konvention pro Sprache ist und kein globales Standard.

Fehler, die Sie vermeiden sollten

• Skalierung um 1000 „für den Fall". Entscheiden Sie anhand des Vertrags, niemals anhand der Größe der Zahl.
• Lokale Zeit ohne Offselt speichern. Die Sommerzeit wird die Arithmetik irgendwann brechen.
• Parsen durch Zerlegen von Strings. Nutzen Sie den Parser der Standardbibliothek: ISO 8601 bringt Wochendaten, Basic-Format und Nachkommastellen mit, die handgeschriebenen Code zerlegen.
• Datumsformate in SQL. Halten Sie den Wert numerisch oder in UTC in der Datenbank und formatieren Sie in der Anwendung, wo Sie Locale und Zeitzone kontrollieren.
• Einen vollständigen Timestamp als menschlichen Code verwenden. Wenn Menschen ihn laut vorlesen, lassen sie Ziffern weg. Runden oder hashen Sie, wenn Sie eine kurze Referenz brauchen.

Ausprobieren

Fügen Sie einen Epoch-Wert oder einen Datumsstring in einen Timestamp-Konverter ein, um zwischen Sekunden, Millisekunden, ISO 8601 und Ihrer lokalen Zeit zu wechseln. Die Konvertierung läuft in Ihrem Browser, damit kein Timestamp — sensibel oder nicht — Ihr Gerät verlassen muss, nur um lesbar zu sein.