Millisekunden zu Datum Konverter

Genau 24 Stunden in Millisekunden zu addieren landet bei 13:00, nicht bei 12:00

Ein Tag hat 86.400.000 Millisekunden, außer an den zwei Tagen im Jahr, an denen er das nicht hat. Addieren Sie das auf den Mittag der Frühjahrsumstellung, und die Uhr zeigt 13:00; tun Sie es im Herbst, zeigt sie 11:00. Die Rechnung stimmt — ein Kalendertag und 24 Stunden sind zweimal im Jahr schlicht verschiedene Dinge.

So wird gerechnet

• Wandelt Millisekunden-Zeitstempel in Daten und zurück, in UTC und Ortszeit.
• Zeigt die Aufschlüsselung in Einheiten, da Millisekundenwerte auf einen Blick schwer lesbar sind.
• Weist auf die Grenze hin, an der ein Date ungültig wird — ein Versagen, das leise statt laut erfolgt.

1 Sekunde = 1.000 ms      1 Stunde = 3.600.000 ms
1 Minute = 60.000 ms      1 Tag    = 86.400.000 ms

JavaScript-Date-Bereich = ±8.640.000.000.000.000 ms
  → +275760-09-13 und −271821-04-20

eine Millisekunde darüber → Invalid Date

Rechenbeispiel

Einen Tag in Millisekunden über jede Zeitumstellung addieren, dazu die Bereichsgrenze.

1. Start 28. März 2026, 12:00 — 86.400.000 ms addieren → 29. März, 13:00
2. Start 24. Oktober 2026, 12:00 — 86.400.000 ms addieren → 25. Oktober, 11:00
3. 8.640.000.000.000.000 ms → +275760-09-13, das Maximum
4. eine Millisekunde mehr → Invalid Date
5. dieses Invalid Date ist weiterhin ein Objekt, und getTime() liefert NaN

Keine der Umstellungen bringt Sie zurück auf 12:00, weil der Kalendertag 23 oder 25 Stunden lang war. Und das Bereichsversagen ist schlimmer als eine Ausnahme: Invalid Date besteht instanceof Date, fließt also weiter und verwandelt jede spätere Rechnung in NaN.

Das Ergebnis lesen

• Nutzen Sie Kalenderarithmetik, wenn Sie 'morgen zur selben Zeit' meinen, und Millisekundenarithmetik, wenn Sie 'in 24 Stunden' meinen. An 363 Tagen im Jahr stimmen sie überein — genau deshalb fällt die Abweichung im Test so selten auf.
• Invalid Date ist der gefährliche Fehlerfall, weil es kein Fehler ist. Es ist ein Date-Objekt, dessen getTime() NaN liefert, und NaN wandert still durch jede Folgeoperation, bis weit stromabwärts etwas leer oder als Null erscheint.
• Die Bereichsgrenze liegt bei ±100.000.000 Tagen ab der Epoche — großzügig genug, dass sie zu erreichen fast immer eine falsche Multiplikation bedeutet und kein echtes Datum, meist Sekunden dort, wo Millisekunden erwartet wurden, was den Wert vertausendfacht.
• Millisekunden passen bequem in den sicheren Ganzzahlbereich, sie können also anders als Nanosekunden in einer gewöhnlichen Zahl leben, ohne Stellen zu verlieren. Das ist der praktische Grund, warum sich die meisten APIs auf Millisekunden festgelegt haben und nicht auf etwas Feineres.

Häufige Fragen

Warum liegt mein Datum nach dem Addieren eines Tages eine Stunde daneben?

Sie haben eine Zeitumstellung überquert. 86.400.000 ms zu addieren fügt genau 24 Stunden hinzu, dieser Kalendertag hatte aber 23 oder 25. Wollten Sie dieselbe Uhrzeit, addieren Sie einen Tag per Kalenderarithmetik statt einer festen Millisekundenzahl.

Was bedeutet Invalid Date?

Der Wert lag außerhalb von ±8.640.000.000.000.000 ms oder ließ sich nicht parsen. Es ist keine Ausnahme — es ist ein Date-Objekt, dessen getTime() NaN ist, das weiter durch Ihren Code fließt und spätere Rechnungen still ebenfalls zu NaN macht.