1894248 - Date parsing inconsistencies with dd-MMM-00yy

Status: RESOLVED FIXED

(Core :: JavaScript: Standard Library, defect, P3)

Description

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Checking the output for

new Date("23-Apr-0024")
new Date("23Apr0024")

firefox 125

• Tue Apr 23 0024 00:00:00 GMT+0017 (Central European Standard Time)
• Tue Apr 23 0024 00:00:00 GMT+0017 (Central European Standard Time)

chrome 125

• Tue Apr 23 2024 00:00:00 GMT+0200 (Central European Summer Time)
• Tue Apr 23 2024 00:00:00 GMT+0200 (Central European Summer Time)

some old version of WebKit:

• Tue Apr 23 2024 00:00:00 GMT+0200 (Central European Summer Time)
• Invalid Date

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

Vinny: In case you'd like to take a peek here, giving you right of first refusal :)

Comment 2

[Vinny Diehl]

Attachment: Bug 1894248 - Fixup all years < 100 r?arai

Comment 3

[Vinny Diehl]

Yup. We were fixing up the year based on number of digits rather than whether it actually needed fixing up (i.e. year < 100). Patch is up :)

Comment 4

[Tom S]

Parsing an explicit 0024 as 2024 is crazy, but I guess thanks to Chrome for introducing such a lenient parsing.

Comment 5

[Vinny Diehl]

:evilpie yeah, for the record I hate this (ISO even parses differently than non-ISO!) , but I guess we're doing it. Yay parity!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/168bad3fbee2
Fixup all years < 100 r=arai

Comment 7

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/168bad3fbee2