So konvertierst du Unix-Zeitstempel
Wähle Automatik, Sekunden, Millisekunden oder ISO-Eingabe. Automatik ist bequem, aber eine explizite Einheit ist für Verträge sicherer. Die Ausgabe zeigt den UTC-ISO-Zeitpunkt, eine lokale Darstellung, die erkannte Einheit und beide Epochwerte.
- Füge eine Ganzzahl oder eine vollständige ISO-8601-Zeit mit Z oder numerischem Offset ein.
- Wähle bei bekannten Daten Sekunden oder Millisekunden explizit; nutze Automatik nur zur Diagnose.
- Prüfe den UTC-ISO-Wert und die lokale Darstellung samt Zeitzonenname.
- Kopiere die gewünschte Sekunden- oder Millisekundenform und bewahre die Einheit im Datenvertrag auf.
Beispiele und erwartetes Verhalten
| Eingabe | Ausgabe | Hinweise |
|---|---|---|
0 Sekunden |
1970-01-01T00:00:00.000Z |
Beginn der Unix-Epoche. |
1722254400 Sekunden |
2024-07-29T12:00:00.000Z |
Eine zehnstellige Ganzzahl wird als Sekunden interpretiert. |
1722254400000 Millisekunden |
2024-07-29T12:00:00.000Z |
Dreizehnstellige Werte sind typischerweise Millisekunden. |
2026-07-29T15:30:00+02:00 |
2026-07-29T13:30:00.000Z |
Der numerische Offset wird in UTC umgerechnet. |
2026-02-30T10:00:00Z |
Ungültiges Datum |
Nicht existierende Kalendertage werden abgelehnt. |
8640000000000001 ms |
Außerhalb des Bereichs |
Werte außerhalb des JavaScript-Date-Bereichs werden nicht normalisiert. |
Unix-Zeit, Sekunden und Millisekunden
Ein Unix-Zeitstempel zählt Zeit seit 1970-01-01T00:00:00Z. Viele APIs verwenden Sekunden, JavaScript Date verwendet Millisekunden. Ein Faktor-1000-Fehler kann ein plausibles, aber völlig falsches Datum erzeugen.
Der Automatikmodus behandelt Beträge ab 100.000.000.000 als Millisekunden und kleinere als Sekunden. Das ist eine dokumentierte Heuristik, keine Eigenschaft des Standards. In Schnittstellen sollte die Einheit immer im Feldnamen oder Schema stehen.
- Sekunden und Millisekunden sind nicht austauschbar.
- Negative Werte liegen vor der Epoche.
- Bruchteile werden für numerische Eingaben nicht akzeptiert.
ISO 8601 und Zeitzonen
ISO-Eingaben benötigen Datum, Uhrzeit und entweder Z oder einen numerischen Offset wie +02:00. Dadurch bezeichnet die Zeichenfolge einen eindeutigen Zeitpunkt. Eine lokale Zeit ohne Offset ist mehrdeutig und wird bewusst abgelehnt.
Die ISO-Ausgabe ist UTC. Die lokale Ausgabe verwendet die aktuelle Browserzeitzone und zeigt deren Namen. Sommerzeit kann den lokalen Offset je Datum ändern; sie verändert nicht den zugrunde liegenden Epochwert.
- Z bedeutet UTC.
- Offsets werden in denselben UTC-Zeitpunkt umgerechnet.
- Lokale Anzeige hängt von Browser- und Betriebssystemeinstellungen ab.
Strikte Gültigkeit und Bereich
JavaScript normalisiert manche ungültige Datumskomponenten stillschweigend, etwa einen überlaufenden Tag. Dieser Konverter prüft Kalendertag, Uhrzeit, Offset und Rückkonvertierung, damit 30. Februar oder 24:00 nicht unbemerkt zu einem anderen Datum werden.
Der unterstützte Bereich folgt Date: maximal ±8.640.000.000.000.000 Millisekunden. Werte darüber, nicht endliche Zahlen, Dezimal- oder Exponentialschreibweise werden abgelehnt, um Einheiten und Rundung eindeutig zu halten.
- Schaltjahre werden kalendarisch geprüft.
- Offset muss innerhalb des zulässigen Bereichs liegen.
- Ungültige Werte liefern keinen Ersatz mit aktuellem Datum.
Lokale Zeit und DST
Ein Epochwert ist absolut; lokale Uhrzeit ist eine Darstellung. Derselbe Zeitpunkt kann je Zone ein anderes Datum besitzen. Bei Sommerzeitumstellungen können lokale Uhrzeiten übersprungen oder doppelt vorkommen.
Speichere für Ereignisse meist UTC-Epoch oder ISO mit Offset und bewahre die beabsichtigte IANA-Zeitzone separat, wenn zukünftige lokale Regeln relevant sind. Dieses Werkzeug konvertiert, plant aber keine wiederkehrenden Termine.
- Serverlogs vorzugsweise in UTC.
- Benutzeroberflächen dürfen lokal formatieren.
- IANA-Zone ist mehr als ein fester Offset.
Typische Anwendungen
Nutze die Seite zum Prüfen von API-Feldern, Datenbankwerten, Token-Ablaufzeiten, Logzeilen, Webhook-Zeitstempeln und Cache-TTL-Diagnosen. Die gleichzeitige Ausgabe beider Einheiten hilft, eine falsche Annahme sichtbar zu machen.
Für sicherheitsrelevante Ablaufprüfungen muss Produktionscode außerdem Uhrenabweichung, erlaubte Fenster und Replay-Schutz berücksichtigen. Ein manuelles Werkzeug ersetzt keine serverseitige Prüfung.
- Sekunden/Millisekunden-Verwechslung finden.
- UTC und lokale Anzeige vergleichen.
- ISO-Offsets kontrollieren.
- Test-Fixtures für Grenzwerte erstellen.
Fehlergrenzen und Nicht-Ziele
Leere, nicht ganzzahlige oder außerhalb des Bereichs liegende Epochwerte sowie ISO-Zeiten ohne Zone werden abgelehnt. Historische und zukünftige lokale Darstellungen hängen von der Zeitzonendatenbank des Systems ab.
Die Seite ist kein Kalender, Cron-Parser, Dauerrechner, NTP-Client oder Zeitzonenplaner. Sie berücksichtigt keine Schaltsekunden, da JavaScript Date und Unixzeit sie in dieser Darstellung nicht separat modellieren.
- Keine Netzzeitsynchronisation.
- Keine natürliche Sprache wie „morgen“.
- Keine Garantie für alte lokale Regeln auf veralteten Systemen.
Abgrenzung zu UUID und JSON
Zeitstempel ordnen Ereignisse zeitlich und können Informationen über Erstellungszeit verraten. UUID v4 ist ein zufälliger Identifikator und enthält in dieser Implementierung keine Zeit. Der JSON-Formatter prüft nur Syntax und kennt keine Datumssemantik.
Kennzeichne Zeitfelder mit Einheit und Zone, statt sie aus Anzahl der Ziffern oder Feldinhalt erraten zu lassen.