Unix-Zeitstempel verstehen und umrechnen
Warum Epochenzeit wichtig ist, die Sekunden-vs.-Millisekunden-Falle — und wie Sie jeden Stempel in lesbare Daten je Zeitzone wandeln.
Weitere Utilities, die gut zu dieser Anleitung passen:
Warum das wichtig ist
Eine Logging-Ingenieurin untersucht einen Alarm bei „1735689600“. Ist das 2025-01-01 00:00:00 UTC (Sekunden) oder 1970-01-21 02:08:09 (Millisekunden fälschlich als Sekunden)? Falsch gewählt verschiebt die Post-Mortem-Zeitleiste um Jahrzehnte. Unix-Stempel sind ideal für Speicher und Rechnen — für Menschen schlecht; Sekunden vs. Millisekunden unterscheiden sich je nach Sprache, Datenbank und API. Ein zuverlässiger Konverter macht die Einheit explizit.
Drei echte Szenarien
1735689600 einfügen — Konverter zeigt 2025-01-01 00:00:00 UTC und 2024-12-31 16:00:00 PST. Zeitzone der betroffenen Nutzerin wählen und weiter.
Schnellere Incident-Triage
Lokales Datum in JST eingeben — Epoche in Sekunden oder Millisekunden kopieren, je nach Scheduler.
Korrekte Epoche im Code
Liste von Epochen einfügen — dekodierte UTC-Daten daneben, zurück ins Spreadsheet.
Lesbarer Report
Schritt für Schritt
Öffnen Sie den Unix-Zeitstempel-Konverter.
Stempel einfügen oder Datum wählen
Automatische Erkennung Sekunden (10 Stellen, ~1973–2286) vs. Millisekunden (13 Stellen). Bei Exoten Dropdown überschreiben.
Dekodiertes Datum in mehreren Zonen
UTC, Browser-Lokalzone und beliebige IANA-Zone (
Asia/Tokyo,America/Sao_Paulo).Umgekehrt
Datum und Uhrzeit in beliebiger Zone — Ausgabe Epoche in Sekunden und Millisekunden.
Im passenden Format kopieren
1735689600,1735689600000, ISO2025-01-01T00:00:00Z, RFC 2822 — je nach Zielsystem.
Eingabe
1735689600 (seconds)Decoded
UTC: 2025-01-01 00:00:00
ISO: 2025-01-01T00:00:00.000Z
Local: 2024-12-31 19:00:00 (UTC-5)Eingabe
1735689600 (mistakenly read as milliseconds)Decoded as ms
UTC: 1970-01-21 02:08:09.600
Profi-Tipps
- Einheit in API-Verträgen festhalten. „Unix-Zeitstempel“ ist mehrdeutig — „Integer Unix-Zeit in Millisekunden“ nicht.
- Negative Stempel vor 1970-01-01 sind gültig — Konverter rendiert korrektes gregorianisches Datum.
- ISO-8601 für Menschen —
2026-04-22T15:30:00Zeindeutig und lexikographisch sortierbar. - Stapel: eine Epoche pro Zeile einfügen.
Typische Stolpersteine
Stolperstein
DST-Überraschung nach Zeitzonen-Umrechnung
Termin 09:00 Pacific im Oktober ≠ November (PDT → PST). Mit IANA-Zone (America/Los_Angeles) rechnen, nicht festem Offset UTC-8 — Konverter berücksichtigt DST.
Stolperstein
JavaScript Date.getTime() vs. Python time.time()
JS liefert Millisekunden; Python Sekunden mit Bruchteil. Beim Portieren explizit ÷1000 oder ×1000. Konverter akzeptiert beides zum Abgleich.
Stolperstein
Year-2038-Problem
Legacy mit vorzeichenbehaftetem 32-Bit-Unix-Zeit: nach 2147483647 (2038-01-19) Überlauf. Migration auf 64-Bit planen.
Wann dieses Tool nicht passt
- Geschäftstage-Arithmetik („5 Arbeitstage“) — Bibliotheken wie
date-fns-business-daysoder ERP-Kalender. - Cron debuggen — Cron-Auswerter für nächste N Ausführungen.
- Kalender-Serientermine (RRULE) — iCalendar-Parser statt flacher Sekunden.
FAQ
Welche Zone hat „Epoche null"?
0 ist 1970-01-01 00:00:00 UTC. Unix-Epoche ist implizit UTC.
Warum springen Daten zweimal im Jahr um eine Stunde?
Sommerzeit — IANA-Zonendatenbank mit regionalen DST-Regeln, Konverter wendet sie an.
Wird Eingabe an einen Server geschickt?
Nein — Browser-Date und Intl.DateTimeFormat; nichts verlässt die Seite.
Nächste Schritte
- Meetingfenster mit dem Zeitzonen-Vergleich planen.
- Weltuhr für häufige Städte: /time-tools/world-clock.
- Feiertage in der Region mit Heute Feiertag prüfen.