Ein Unix-Zeitstempel bezeichnet einen Zeitpunkt durch seinen Abstand zur Epoche. Die Ziffern verraten jedoch nicht, ob sie Sekunden oder Millisekunden zählen. Auch eine Datumsschreibweise ist riskant: Ohne Z oder ausdrücklichen Offset kann dieselbe Uhrzeit verschiedene Zeitpunkte meinen. Verlässliche Konvertierung zeigt Einheit, Zone und Randfälle.
Diese Anleitung verfolgt mit dem Unix-Zeitstempel-Konverter eine halbe Sekunde vor der Epoche. Das feste Beispiel erklärt negative Werte, Bruchteile, UTC, Offsets und lokale Anzeige.
Zeitpunkt, Einheit und Anzeigezone bestimmen
Die Epoche ist 1970-01-01T00:00:00Z. Null Sekunden und null Millisekunden sind derselbe Zeitpunkt. Abseits davon ist die Einheit entscheidend: 1000 Sekunden sind sechzehn Minuten und vierzig Sekunden, 1000 Millisekunden nur eine Sekunde. Das Werkzeug rät die Einheit nicht aus der Stellenzahl, weil kurze historische und künftige Werte diese Heuristik unzuverlässig machen.
Die UTC-ISO-Ausgabe beschreibt den Zeitpunkt stabil. Die lokale Ausgabe stellt denselben Punkt mit der erkannten Browserzeitzone dar und nennt diese Zone. Eine andere Uhrzeit bedeutet nicht, dass der Zeitstempel verändert wurde. Speichere und vergleiche zuerst den Zeitpunkt; lokalisiere ihn nur für die Anzeige.
Ein Randfall vor 1970
Verwende unverändert:
1969-12-31T23:59:59.500Z
Als Millisekunden ergibt sich -500, als ganze Sekunden -1, weil gegen minus unendlich abgerundet wird. Abschneiden gegen null ergäbe 0 und würde einen Zeitpunkt vor der Epoche fälschlich auf die Epoche setzen.
Prüfe außerdem:
1970-01-01T01:00:00+01:00
Das ergibt in beiden Einheiten 0. Die geschriebene Uhr zeigt 01:00, der Offset +01:00 bezeichnet aber Mitternacht UTC. Beide Beispiele sind von der lokalen Rechnerzone unabhängig.
In beide Richtungen konvertieren
Wähle ISO nach Zeitstempel, füge den ersten Wert ein und wähle Millisekunden. Erwarte -500. Wechsle zu Sekunden und erwarte -1. Kopiere jedes Ergebnis einzeln und notiere die Einheit.
Füge den zweiten Wert ein und bestätige null. Wechsle danach zur Gegenrichtung, gib -500 ein und wähle Millisekunden. UTC muss wieder 1969-12-31T23:59:59.500Z ergeben. Die lokale Darstellung darf ein anderes Datum zeigen, muss aber denselben Zeitpunkt und ihre Zone nennen.
„Jetzt“ erfasst den Moment beim Klick; es ist keine Serveruhr und läuft beim SSR nicht fort. Bewahre zur Fehlersuche Zahlenwert, Einheit, UTC-ISO und Zone zusammen auf. Stecke einen Millisekundenwert nicht versuchsweise in das Sekundenfeld, nur weil das Ergebnis plausibel aussehen soll.
Weshalb strenges ISO und Abrunden wichtig sind
Die Rückrichtung akzeptiert vollständiges Datum und Uhrzeit mit Z oder numerischem Offset. 2026-09-17T10:00:00 wird abgewiesen, weil kein eindeutiger Zeitpunkt feststeht. Kalenderbestandteile werden vor der Date-Erzeugung geprüft; 2026-02-30T00:00:00Z wird nicht still in den März verschoben.
ECMAScript stellt Zeit als Millisekunden relativ zur Epoche dar und begrenzt den Date-Bereich. Das Werkzeug verlangt zusätzlich sichere Ganzzahlen, prüft den Bereich und begrenzt Eingaben auf 100 Zeichen. ISO-Bruchteile dürfen ein bis drei Stellen haben. So unterscheiden Meldungen Syntax, Präzision und Bereich.
Mathematisches Floor ordnet einen Bruchteil der enthaltenen ganzen Sekunde zu. 0,5 Sekunden werden 0, -0,5 wird -1. Dadurch bleibt die Reihenfolge rund um die Epoche richtig.
Unplausible Daten untersuchen
Ein Datum nahe 1970 oder extrem weit in der Zukunft weist oft auf die falsche Einheit hin. Lies den Vertrag der Quelle, bevor du mit 1.000 multiplizierst oder dividierst. Eine API kann verschiedene Felder unterschiedlich definieren.
Ungültiges Datum kann fehlende Zone, unmöglichen Tag oder nicht unterstützte Syntax bedeuten. Verwende etwa 2026-09-17T10:00:00Z oder 2026-09-17T12:00:00+02:00. Ein bloßes Datum oder 17.09.2026 10:00 benennt keinen eindeutigen Zeitpunkt.
Unsichere oder außerhalb des Bereichs liegende Ganzzahlen dürfen nicht passend gerundet werden. Bewahre den Originaltext und kläre ihn mit dem Erzeuger. Bei überraschender Ortszeit kontrolliere Zone und UTC vor einer Wertänderung. Für Mikro- oder Nanosekunden ist ein anderes Werkzeug mit dokumentierter Rundungsregel nötig.
In echten Abläufen richtig einsetzen
Vergleiche bei Token-Ablauf nur gleiche Einheiten und dokumentiere, ob die Grenze einschließlich gilt. Ein dekodiertes Ablaufdatum prüft weder Signatur noch Berechtigung. Bei Logs bleiben UTC und Originalzeitstempel erhalten; Ortszeit ist Darstellung. Datenbankspalten müssen die Quellpräzision tragen.
Ein Offset stellt die Beziehung zu UTC an diesem Zeitpunkt dar, aber keine vollständige Zeitzonenregel. +02:00 ist nicht gleichbedeutend mit Europe/Berlin und beschreibt keine künftige Sommerzeit. Für zivile Termine speichere eine IANA-Zone separat.
Die Verarbeitung läuft im Browser. Verwende trotzdem keine Screenshots echter Tokens oder Logs als Beispiel. Ersetze Kennungen und Inhalte durch synthetische Werte. Für Audits speichere Originaltext, Einheit, normalisierte UTC-Ausgabe und gegebenenfalls die fachliche IANA-Zone als getrennte Angaben.
Grenzen des Konverters
Unterstützt werden sichere Ganzzahlen in ausdrücklich gewählten Sekunden oder Millisekunden und strenge ISO-Zeitangaben mit Z oder Offset. Nicht unterstützt werden Einheitenraten, regionale Freitextdaten, Schaltsekunden, Genauigkeit unter Millisekunden oder das Ableiten eines Zonennamens. Sekundenresultate verlieren Bruchteile durch Floor, auch negativ.
Lokale Formatierung hängt vom Browser und seiner Zeitzonendatenbank ab. Sie ist Anzeigehilfe, kein Beweis historischer Behördenregeln. Die Umrechnung kann auch nicht zeigen, ob ein Wert vertrauenswürdig, aktuell, signiert oder fachlich das richtige Feld ist. Das muss das Quellprotokoll sichern.
Abschließende Zeitstempelprüfung
Benenne Quellfeld und dokumentierte Einheit, behalte den Originaltext und teste null, einen bekannten Wert und den negativen Randfall. ISO braucht reales Kalenderdatum plus Z oder Offset. Kontrolliere UTC vor Ortszeit und notiere die angezeigte Zone.
Erwarte -500 ms und -1 s für 1969-12-31T23:59:59.500Z, null für 1970-01-01T01:00:00+01:00 und Ablehnung von 2026-02-30T00:00:00Z. Konvertiere einen dokumentierten Gegenwartswert hin und zurück und vergleiche die normalisierte UTC-Form exakt. Teste bei Ablaufwerten unmittelbar vor, auf und nach der Grenze.
Prüfe außerdem je einen zulässigen negativen Sekunden- und Millisekundenwert, damit die Einheitenauswahl nicht nur bei null funktioniert. Kopiere Ergebnisse mit sichtbarer Einheit in den Testbericht. Bei einem Fehler darf keine alte Ausgabe einer früheren erfolgreichen Konvertierung als aktuelles Ergebnis übernommen werden.
Für Logs solltest du drei Ebenen trennen: unveränderter Quellwert, normalisierte UTC-Darstellung und lokal formatierte Ansicht. Nur die ersten beiden eignen sich zum reproduzierbaren Vergleich. Eine Änderung der Browserzone darf ausschließlich die dritte Ebene ändern. Teste denselben UTC-Wert in zwei bekannten Zonen, ohne den Zeitstempel neu zu berechnen.
Bei Ablaufprüfungen kommt zur Einheit die Uhrenquelle hinzu. Dokumentiere, welche Uhr den aktuellen Zeitpunkt liefert und wie Toleranzen behandelt werden. Der Konverter bewertet weder Netzwerklatenz noch Clock Skew oder Vertrauenswürdigkeit eines Tokens. Er liefert nur die nachvollziehbare Umrechnung.
Sendet die Quelle mehr als drei Nachkommastellen, entscheide außerhalb dieses Werkzeugs über Präzisionsverlust. Runde oder kürze nicht ohne fachliche Regel. Bewahre den hochpräzisen Originalwert und notiere die Transformation. Teste besonders einen negativen Bruchteil, weil Abrunden und Abschneiden dort verschiedene Sekunden ergeben.
Lege bei Datenaustausch außerdem fest, ob Zeitstempel als JSON-Zahl oder Zeichenkette transportiert werden. Eine Zeichenkette bewahrt sehr große Ziffernfolgen, benötigt aber eine spätere validierte Umwandlung; eine Zahl unterliegt dem sicheren Ganzzahlbereich der Laufzeit. Mische beide Darstellungen nicht still im selben Feld. Schreibe Einheit und Transporttyp in Schema, API-Dokumentation und Testdaten.
Bei einer lokalen Anzeige rund um Sommerzeitwechsel darf dieselbe Zone unterschiedliche Offsets liefern. Das ist kein Konvertierungsfehler. Vergleiche den zugrunde liegenden UTC-Zeitpunkt und zeige den Offset neben der Ortszeit. Für eine fachliche Tagesgrenze muss die Anwendung ausdrücklich entscheiden, welche Zone gilt; der Browserstandard des jeweiligen Betrachters ist dafür zu wechselhaft.
Bewahre diese Zonenentscheidung zusammen mit den Grenzfalltests auf, damit spätere Änderungen der Zeitzonendatenbank überprüfbar bleiben.
Dauerhaft.
Quellen: ECMAScript Date Objects, ECMAScript Date Time String Format und RFC 3339.