JavaScript-Datums-Parser: Versteckte Fehler und Korrekturen

Die gefährliche JavaScript-Datumsanalyse: So vermeiden Sie Parsing-Fehler

Der new Date(string)-Konstruktor in JavaScript versucht, ein Datum aus jeder Zeichenkette zu extrahieren – oft mit unerwarteten Ergebnissen. Das ist kein Bug, sondern eine Funktion der V8- und SpiderMonkey-Engines, die Text aggressiv interpretieren.

Beispiele verdeutlichen das Problem:

new Date("2020-01-23")
// Mi, 22. Jan. 2020 19:00:00 GMT-0500 (als UTC interpretiert)

new Date("Heute ist 2020-01-23")
// Do, 23. Jan. 2020 00:00:00 GMT-0500 (lokale Zeit)

new Date("Route 66")
// Sa, 1. Jan. 1966 00:00:00 GMT-0500

new Date("Beverly Hills, 90210")
// Mo, 1. Jan. 90210 00:00:00 GMT-0500

Diese Umwandlungen erzeugen gültige Date-Objekte mit falschen Werten – was die Fehlersuche erschwert. Der "Catch-22"-Fall liefert Invalid Date, was selten, aber tatsächlich korrekt ist.

Wie der V8-Parser funktioniert

Die ECMAScript-Spezifikation verlangt nur die Analyse eines Teils von ISO 8601. Alles andere ist implementierungsabhängig.

V8-Algorithmen:

• Prüfung auf ISO 8601: String muss mit einer vierstelligen Jahreszahl oder einem Vorzeichen beginnen.
• Rückfall auf den alten Parser: Wörter werden ignoriert, bis die erste Zahl gefunden wird.
• Verarbeitung der Zahlen im DayComposer:

- 1–12: als Monat interpretiert.

- 13–31: mehrdeutig, oft abgelehnt.

- 32+: als Jahr behandelt (50–99 +1900).

- Standard: 1. Januar.

Das erklärt, warum "Route 66" zu 1966 und "90210" zum Jahr 90210 wird.

Zeitzone-Verwirrung

ISO-Strings wie "2020-01-23" werden als UTC geparst, während alte Formate lokale Zeit verwenden. Der Unterschied liegt in den Präfixen:

• Reiner ISO-String: wird als UTC geparst.
• Strings mit Text: Legacy-Modus, lokale Zeit.

Leerzeichen am Anfang oder Ende ändern das Verhalten des Parsers und verschieben das Ergebnis um bis zu einem Tag, je nach Zeitzone.

Safari (JavaScriptCore) ist strenger: Er lehnt alte Beispiele und Strings mit nachfolgenden Leerzeichen ab.

Praxisfehler und Lösungen

In echten Projekten kann der Rückgriff auf new Date() bei Benutzereingaben dazu führen, dass "Route 66" zu einem Datum wird und Datenbanktabellen beschädigt werden. Lösung: Nur benutzerdefinierte Parser mit Regex-Validierung nutzen.

Best Practices für mittlere und erfahrene Entwickler:

• Format mit Regex validieren, bevor new Date() aufgerufen wird.
• Für strikte ISO-Parsetechnik date-fns parseISO() verwenden.
• Für volle Kontrolle Bibliotheken wie Luxon oder Day.js mit eigenen Parsern nutzen.
• new Date(string) niemals mit unverifizierten Eingaben verwenden.
• Über Browser hinweg testen: V8, SpiderMonkey, JSC.

JavaScript vs. Python: Ein Vergleich

Python vermeidet Mehrdeutigkeit:

• datetime.fromisoformat(): akzeptiert nur ISO 8601.
• strptime(): striktes Format, keine zusätzlichen Zeichen erlaubt.

JavaScripts alter Parser ratet stillschweigend; Python wirft einen ValueError.

Wichtige Erkenntnisse

• Der Date-Parser erstellt gültige, aber falsche Objekte aus beliebigem Text.
• Das Verhalten des Parsers (ISO vs. Legacy) hängt von Präfixen und Leerzeichen ab.
• In Produktion: immer Eingaben vor dem Parsen validieren.
• Migratieren Sie zur Temporal-API für zukunftssichere Code.
• Cross-Browser-Tests sind aufgrund der Engine-Unterschiede essenziell.

— Editorial Team