Unix-Zeitstempel: Sekunden, Millisekunden und das falsche Datum
Vier Eingaben, ein Moment. Finde heraus, warum ein Zeitstempel im Jahr 1970 oder am falschen Tag landen kann.
Ein Zeitstempel, der im Januar 1970 landet, hat oft die falsche Einheit. Die Zahl 1792069200 gibt Unix-Sekunden an; 1792069200000 ist derselbe Moment in Millisekunden. Für keine der beiden musst du vor der Konvertierung einen Zeitzonen-Offset hinzufügen.
Öffne den Zeitzonen-Konverter, klappe Datum oder Zeitstempel einfügen auf, füge eine der Zahlen ein und wähle Konvertieren. Prüfe die Interpretation unter dem Formular. Beide sollten 2026-10-15T13:00:00.000Z ergeben.
Vier Möglichkeiten, denselben Moment zu schreiben
Probiere diese nacheinander aus oder lade die vier Zeitstempel-Beispiele herunter:
1792069200
1792069200000
2026-10-15T13:00:00Z
2026-10-16T00:00:00+11:00
Die letzte Zeile ist bereits Mitternacht am nächsten Tag, stellt aber denselben Moment dar. Ihr expliziter Elf-Stunden-Offset erklärt den Unterschied.
Das Tool liest die erste Zahl als Sekunden und die zweite als Millisekunden. Bei aktuellen Datumswerten sind 10 statt 13 Stellen ein nützlicher Hinweis, aber keine universelle Definition eines Zeitstempels. Dieser Konverter lehnt 11- und 12-stellige numerische Eingaben ab, statt zu raten. Er unterstützt Datumswerte von 1900 bis 2100; er ist kein Parser für jedes historische Zeitstempelformat.
Wenn du JavaScript schreibst, erwartet der numerische Date-Konstruktor Millisekunden. MDNs Date-Referenz dokumentiert diese Einheit. Sekunden mit 1.000 zu multiplizieren ist eine Einheitenumrechnung, keine Zeitzonenanpassung.
Prüfe das Datum ebenso wie die Uhrzeit
Nutze Zeitzone hinzufügen, um die Städte einzubeziehen, die du brauchst. Für das obige Beispiel sind die getesteten Ergebnisse:
| Zeitzone | Lokales Datum und Uhrzeit | UTC-Offset an diesem Datum |
|---|---|---|
| UTC | 15. Oktober 2026, 13:00 | +00:00 |
| Australia/Melbourne | 16. Oktober 2026, 00:00 | +11:00 |
| Europe/London | 15. Oktober 2026, 14:00 | +01:00 |
| America/New_York | 15. Oktober 2026, 09:00 | -04:00 |
Diese Offsets gehören zum Beispieldatum. Verwende sie nicht als dauerhafte Unterschiede zwischen Städten; die Sommerzeit kann die Differenz ändern. Für eine wiederkehrende Aufgabe siehe das Cron- und Sommerzeit-Beispiel.
Ziehen innerhalb einer Uhrenkarte verschiebt den gemeinsamen Moment, sodass sich alle Karten gemeinsam aktualisieren. Alle Zeiten kopieren kopiert auch das Datum und den Offset. Das ist für einen Kollegen nützlicher, als nur „9 Uhr“ zu senden.
Ein Datum ohne Offset ist eine andere Eingabe
Füge 2026-10-15T13:00 ein und setze Ohne Zeitzone, lesen als auf Australia/Melbourne. Es wird 2026-10-15T02:00:00.000Z, elf Stunden früher als unser erstes Beispiel.
Das ist kein Fehler: Diesmal hast du eine lokale Uhrzeit angegeben, und die Quellzeitzone lieferte den fehlenden Kontext. Bei einer Unix-Zahl oder einem expliziten Offset verschiebt diese Quellenauswahl den Moment nicht. Meine Zeitzone kann die Zone deines Geräts hinzufügen, aber dein Gerät kann dir nicht sagen, welche Zeitzone ein unbeschrifteter Log-Eintrag ursprünglich verwendet hat.
Mehrdeutige Eingaben vor dem Teilen klären
Das Tool fragt bei mehreren Eingaben bewusst nach:
10/11/2026 09:00könnte den 11. Oktober oder den 10. November bedeuten. Verwende ein Datum im Format Jahr-Monat-Tag.2026-10-15 09:00 CSTverwendet eine mehrdeutige Abkürzung. Wähle eine vollständige Quellzeitzone oder gib einen expliziten UTC-Offset an.2026-11-01T01:30inAmerica/New_Yorktritt zweimal auf, wenn die Uhren zurückgestellt werden. Gib den beabsichtigten Offset an; eine lokale Uhrzeit allein kann nicht zwischen ihnen wählen.
Wir haben diese Eingaben und die vier äquivalenten Zeitstempel am 15. Oktober 2026 gegen den Parser des Tools geprüft. Die Konvertierungsausgabe und der Ergebnisdatensatz bewahren die exakten Werte. Die Verarbeitung natürlicher Sprache variiert je nach Sprache; ein explizites Datum und ein Offset sind die bessere Wahl, wenn die Zeit eindeutig sein muss.