Millisekunde Zu Datum

Sie haben eine lange Ganzzahl in einer Log-Zeile, einer API-Antwort oder einem Date.now()-Rueckgabewert sitzen und muessen sie als Kalenderdatum lesen. Fuegen Sie den 13-stelligen Wert in den Konverter ein; die Seite liest ihn als Datum in Ihrer lokalen Zeitzone direkt im Browser zurueck. Das Feld oeffnet sich vorbelegt mit der aktuellen Millisekunde, sodass die erwartete Form bereits auf dem Bildschirm ist.

Zuletzt geprueft: 2026-05-20

Geprueft vom FreetoolOnline-Redaktionsteam

Log-Zeilen speichern selten eine saubere Ganzzahl. Ein Feld kann als 1713538800000ms geschrieben sein, die Kommentarspalte kann es als 1713538800000 millis markieren oder ein JSON-Payload kann die Zahl in Anfuehrungszeichen einschliessen. Alle drei Formen werden sauber eingefuegt, weil der Konverter die Eingabe in eine Number zwingt, bevor er das Date konstruiert. Nachgestellte Buchstaben und umgebende Leerzeichen werden ignoriert, sodass Sie den Wert direkt aus dem umgebenden Log-Rauschen greifen koennen, ohne ihn zuerst zu putzen. Wenn das Ergebnis in 1970 landet, war die Eingabe fast sicher Unix-Sekunden, nicht Millisekunden; multiplizieren Sie mit 1000 oder verwenden Sie stattdessen ein Sekunden-zu-Datum-Werkzeug.

Das Ergebnis in Ihrer lokalen Zeitzone zurueck lesen

Der Konverter rendert das Datum mit dem Locale und der Zeitzone des Browsers, was dem entspricht, was ein Kollege auf derselben Maschine sehen wuerde, wenn er new Date(value).toString() in der Entwicklerkonsole aufruft. Das ist meistens das, was ein Entwickler, der eine Vorfall-Timeline liest, will: die Wanduhrzeit, zu der das Ereignis in seiner Arbeitszeitzone gelandet ist, nicht der abstrakte UTC-Wert, den der Log speichert. Wenn die Seite waehrend eines Sommerzeit-Uebergangs offen ist, malt dieselbe Eingabe-Millisekunde vor und nach dem Schnitt eine andere Wanduhrzeit - die zugrunde liegende Ganzzahl aendert sich nicht, aber der Offset, den der Browser anwendet, schon.

Um eine UTC-Lesung anstelle des Standard-Lokalzonen-Verhaltens zu erzwingen, wechseln Sie die Systemzeitzone (oder verwenden Sie ein privates Browserfenster mit einem UTC-gesperrten Profil) und laden Sie den Konverter neu. Die Konvertierungslogik ist deterministisch - dieselbe Eingabe produziert immer dieselbe Ausgabe fuer eine gegebene Zeitzonen-Einstellung - sodass die Seite geeignet ist, in eine Ticket-Antwort oder einen Code-Review-Kommentar einzufuegen, wenn Leser und Schreiber ihren Browser zuerst auf dieselbe Zeitzone setzen.

Haeufige 13-stellige Eingaben, die der Konverter akzeptiert

Die haeufigsten Formen, mit denen der Konverter umgehen musste:

• Rohe Ganzzahl. Eine reine 13-stellige Zahl wie 1713538800000, oft aus einer Datenbankspalte oder Log-Zeile eingefuegt.
• Mit Einheit-Suffix. Ein Wert wie 1713538800000ms oder 1713538800000 millis, ueblich in Monitoring-Dashboards.
• JSON-Anfuehrungszeichen. Ein in Anfuehrungszeichen eingeschlossener Wert wie "1713538800000", direkt aus einem JSON-Payload kopiert.
• Komma-getrennt. Ein Wert mit Tausendertrennzeichen wie 1,713,538,800,000, ueblich in Tabellenkalkulationsexporten.
• Leerzeichen-aufgepolstert. Ein Wert mit fuehrenden oder nachfolgenden Leerzeichen aus einer Mehrfach-Spalten-Einfuegung.

Jede Form wird normalisiert, indem nicht-numerische Zeichen entfernt werden, bevor der Number()-Zwang laeuft, sodass der Leser jede davon einfuegen kann, ohne den Wert zuerst zu putzen.

Wenn das implementierende Werkzeug unter https://freetoolonline.com/utility-tools/convert-time-in-millisecond-to-date.html eine leere Ausgabe zeigt, ist die haeufigste Ursache ein Wert, der auf dem Weg durch die Zwischenablage eine Ziffer verloren hat (12 Ziffern werden als Jahr 5878 oder frueher gelesen). Kopieren Sie den vollstaendigen Wert erneut, fuegen Sie ihn ein und das Datum sollte wie erwartet erscheinen.