Unix-Timestamps erklärt - Epoch, ISO-8601 und Zeitzonen
Ein Unix-Timestamp kodiert Zeit als ganze Zahl - Sekunden (10 Stellen) oder Millisekunden (13 Stellen) seit dem 1. Januar 1970 UTC. ISO 8601 und RFC 2822 fügen menschenlesbare Strings mit Zeitzone für den Datenaustausch hinzu. Diese Anleitung erklart, wie man zwischen den drei Formaten konvertiert, den Off-by-1000-Fehler vermeidet und DST korrekt behandelt.
Unix-Epoch: Sekunden seit 1970-01-01 UTC
Der Unix-Timestamp - auch "Epoch-Zeit" genannt - ist die Anzahl der Sekunden, die seit 00:00:00 UTC am 1. Januar 1970 vergangen sind. Dieser Referenzpunkt ist willkürlich, aber universell; jedes von Unix abgeleitete System (Linux, macOS, Android, iOS) und fast jede Programmiersprache verfolgt die Zeit intern als Zählung von diesem Moment aus.
Ein aktueller Wert: 1776495426 übersetzt sich zu 2026-04-18 12:17:06 UTC. Es gibt keine Zeitzone, die in der Zahl selbst kodiert ist - sie ist immer UTC - was sowohl eine Stärke (keine Ambiguität, wenn zwei Systeme Timestamps vergleichen) als auch eine Falle ist (was auch immer die Zahl in einen menschenlesbaren String konvertiert, muss eine Zeitzone wählen, und es wählt normalerweise die lokale).
Sekunden vs Millisekunden: die erste Quelle der Verwirrung
JavaScript, Java und die meisten modernen Sprach-Standardbibliotheken verwenden standardmäßig Millisekunden seit dem Epoch, nicht Sekunden. Derselbe Moment - 2026-04-18 12:17:06 UTC - ist 1776495426 in Sekunden (10 Ziffern), aber 1776495426000 in Millisekunden (13 Ziffern). Eine schnelle Faustregel zur Plausibilitätsprüfung eines Timestamps, den Sie erhalten haben:
- 10 Ziffern → Sekunden (Unix-Kommandozeile, PHP, Python
time.time(), Go). - 13 Ziffern → Millisekunden (JavaScript
Date.now(), JavaSystem.currentTimeMillis(), die meisten JSON-APIs). - 16 oder 19 Ziffern → Mikrosekunden oder Nanosekunden (spezialisierte Telemetrie und wissenschaftliche Zeitmessung).
Ein 10-stelliger Sekundenwert, der als Millisekunden interpretiert wird, rendert als Datum im Jahr 1970 (50+ Jahre zu früh). Ein 13-stelliger Millisekundenwert, der als Sekunden interpretiert wird, rendert als Datum ~56.000 n. Chr. Beide Fehler sind sofort sichtbar, sobald der Timestamp konvertiert wird - verwenden Sie Convert Milliseconds to Date zur Plausibilitätsprüfung oder Get Current Time in Milliseconds zum Vergleich mit dem Jetzt.
ISO 8601: das lesbare Austauschformat
ISO 8601 ist ein menschenlesbares Datums-Zeit-Format, dem auch Maschinen zustimmen. Die kanonische Form sieht so aus: 2026-04-18T12:17:06.520Z. Teile:
- Datum:
2026-04-18(YYYY-MM-DD, immer in dieser Reihenfolge). - Trennzeichen:
T(literaler Buchstabe T zwischen Datum und Zeit). - Zeit:
12:17:06.520(HH:MM:SS.sss, 24 Stunden). - Zeitzone:
Zfür UTC oder ein Offset wie+07:00/-05:30für andere Zonen.
ISO 8601 ist eindeutig (keine regionale Datumsverwirrung wie 04-18 vs 18-04), sortierbar als einfacher String (die lexikalische Reihenfolge entspricht der chronologischen Reihenfolge, wenn die Zeitzone gleich ist), und wird von jedem modernen Parser unterstützt. Wenn Sie die API kontrollieren, die Sie bauen, bevorzugen Sie ISO-8601-Strings gegenüber rohen Unix-Epoch-Zahlen - sie tragen die Zeitzone explizit, was eine ganze Klasse von Bugs eliminiert.
RFC 2822: das alte E-Mail- und HTTP-Format
RFC 2822 (und das fast identische HTTP-Datum aus RFC 7231) sieht so aus: Sat, 18 Apr 2026 12:17:06 +0000. Es ist das Format, das Sie in E-Mail-Date:-Headern, HTTP-Last-Modified-Headern und einigen älteren Web-APIs sehen werden. Es ist lesbar, aber nicht als einfacher String sortierbar (das Wochentags-Präfix bricht die lexikalische Reihenfolge), so dass Systeme zunehmend ISO 8601 neben oder anstelle von RFC 2822 zurückgeben. Wenn Sie RFC 2822 manuell generieren müssen, verwenden Sie eine Bibliothek, anstatt den String selbst zu bauen - der Wochentagsname und die Monatsabkürzung sind locale-sensitiv und leicht zu verwechseln.
UTC vs Ortszeit: die Wurzel der meisten Timestamp-Bugs
Unix-Epoch-Timestamps sind immer UTC; ISO-8601-Strings können UTC (Z) oder jeder Offset sein; RFC 2822 trägt fast immer einen Offset. Aber wenn ein Programm einen Timestamp anzeigt, konvertiert es normalerweise in die lokale Zeitzone der anzeigenden Maschine.
Das ist für einen einzelnen Benutzer in Ordnung, verursacht aber in drei Szenarien Chaos:
- Einen Timestamp im Chat teilen. "Der Deploy passierte um 14:00" ist mehrdeutig - wessen 14:00? Fügen Sie den ISO-8601-Wert (
2026-04-18T14:00:00+07:00) ein oder geben Sie die Zeitzone explizit an. - Logs von mehreren Servern. Setzen Sie jeden Server auf UTC. Immer. Log-Aggregatoren und Incident-Response-Tools nehmen UTC an; das Mischen von Zeitzonen in Logs ist der schnellste Weg, eine Ursache-Wirkungs-Kette falsch zuzuordnen.
- Benutzerorientierte Zeitpläne. Speichern Sie die Ereigniszeit in UTC (oder in der Quellzeitzone des Ereignisses mit explizitem Offset) und konvertieren Sie zur Anzeigezeit. Speichern Sie nicht "19 Uhr" ohne Zeitzone; "19 Uhr" in der Sitzung eines Benutzers kann 16 Uhr für einen anderen sein.
Drei häufige Fallstricke (und wie man sie erkennt)
1. Integer-vs-String-Timestamps in JSON. JavaScripts JSON.parse erzeugt treu eine Zahl für 1776495426520 - aber wenn die API denselben Timestamp als String "1776495426520" zurückgegeben hat, wird jeder nachfolgende Code, der Arithmetik darauf ausführt, ihn stillschweigend coercen. Prüfen Sie immer den Typ, bevor Sie ihn an new Date() übergeben.
2. Monat 0-11 in JavaScript Date. new Date(2026, 3, 18) ist der 18. April 2026, nicht der 18. März 2026. Der Monat ist 0-indiziert, aber Tag und Jahr sind 1-indiziert. Bevorzugen Sie den ISO-8601-Konstruktor (new Date("2026-04-18")), der der natürlichen Nummerierung folgt.
3. DST-Übergänge. In der Nacht "Vorstellen", existiert 2:30 Uhr Ortszeit nicht; in der Nacht "Zurückstellen", passiert 1:30 Uhr zweimal. Wenn Ihr System lokale Zeitstrings speichert, erzeugen diese Momente unmögliche oder duplizierte Timestamps. UTC-Speicherung beseitigt das Problem; Date-Bibliotheken wie Luxon oder date-fns-tz behandeln die Konvertierung explizit.
Verwandte Werkzeuge
- Convert Milliseconds to Date - Timestamp einfügen, formatierte UTC- und Ortsdatum erhalten.
- Get Current Time in Milliseconds - Live-Epoch-Ablesung, jede Sekunde aktualisiert.
- MD5 Converter - String für Checksums oder Deduplikationsschlüssel hashen.
- JSON Parser - API-Antworten mit Timestamp-Feldern inspizieren.
- Current millis - Unix-Timestamp live in Millisekunden - Begleitleitfaden zum Ablesen des aktuellen Epoch-Werts in Echtzeit.
- Ist diese lange Zahl Millisekunden oder Sekunden? - verwende dies, wenn du eine unbekannte Zahl erhältst und die Präzision vor dem Parsen bestätigen musst.
Why trust these tools
- Ten-plus years of web tooling. The freetoolonline editorial team has shipped browser-based utilities since 2015. The goal has never changed: get you to a working output fast, without an install.
- No install, no sign-up. Open a tool and get a working output in seconds - nothing to download and no account to create. Tools that need heavy processing run it on our service, so even a low-powered machine gets the job done.
- Analytics stops at the page view. We measure which pages get visited, not what you type or upload inside a tool. There is nothing to sign in to and no profile is attached to your input.
- Open-source core components. The processing engines underneath (libheif, libde265, pdf-lib, terser, clean-css, ffmpeg.wasm, and others) are public and audit-able. We link to each one in its tool page's footer.
- Free, with or without ads. All tools are fully functional without sign-up. The Disable Ads button in the header is always available if you need a distraction-free run.