Bug 283825 – non standard new Date('2024-12-3') yields to Invalid Date

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Sebastian Schlatow]

new Date('2024-12-3') yields to: Invalid Date

Date.parse('2024-12-3') yields to: NaN

Firefox:

new Date('2024-12-3') yields to: Date Tue Dec 03 2024 00:00:00 GMT+0100 (Central European Standard Time)

Date.parse('2024-12-3') yields to: 1733180400000

Chromium:

new Date('2024-12-3') yields to: Tue Dec 03 2024 00:00:00 GMT+0100 (Central European Standard Time)

Date.parse('2024-12-3') yields to: 1733180400000

[Karl Dubost]

> the value produced by this function is implementation-defined when given any String value that does not conform to the Date Time String Format (21.4.1.32) and that could not be produced in that implementation by the toString or toUTCString method.

While this leads to an identical result in Firefox and Chrome. 
Per sec this is an implementation defined format. 

https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-date-time-string-format

@Sebastian,

did you notice a website breaking because of this?

[Karl Dubost]

The valid format per spec is `YYYY-MM-DDTHH:mm:ss.sssZ` or a truncation of it.

[Sebastian Schlatow]

> did you notice a website breaking because of this?

@Karl yes, our inhouse webapp, but we found a work around ;)

But nonetheless it would be great if it were more robust.

[Radar WebKit Bug Importer]

<rdar://problem/141044926>

[Karl Dubost]

Bug 223166 is the bug for the implementation of Temporal.
It doesn't fix this specific issue, but it helps figure out the priorities. 
It would be interesting to dig if there have been more compat issues reported because of this.

[Karl Dubost]

The code might be here. 
https://searchfox.org/wubkat/rev/52d16c972a163b36fe64a99efb66af93c6e2f2b2/Source/WTF/wtf/DateMath.cpp#728-762

[Karl Dubost]

ha no, this was for "2024/12/03".
The standard parsing with dashese is at 
https://searchfox.org/wubkat/rev/52d16c972a163b36fe64a99efb66af93c6e2f2b2/Source/WTF/wtf/DateMath.cpp#616-673

[Karl Dubost]

which calls parseES5DatePortion(std::span<const LChar>& currentPosition, int& year, long& month, long& day)
https://searchfox.org/wubkat/rev/52d16c972a163b36fe64a99efb66af93c6e2f2b2/Source/WTF/wtf/DateMath.cpp#448-490

I guess many people are running into this issue as it works in the other browsers and it should work according to spec. There are also many reports and questions online, like on StackOverflow, where this post from 2010 is, I think, the most popular of these posts, with 256k views: https://stackoverflow.com/questions/4310953/invalid-date-in-safari

Here is an interesting use case, as the value of an input type="date" is in the format YYYY-MM-DD: https://stackoverflow.com/questions/3085937/safari-js-cannot-parse-yyyy-mm-dd-date-format

[Karl Dubost]

>  as it works in the other browsers and it should work according to spec

See above. The spec says:

DD	is the day of the month as two decimal digits from 01 to 31.

So this is not defined in the spec. In the spec there is sometimes the mention "Implementation-defined" which is also areas which are NOT defined by the spec. Just to be clear. :) 

But I didn't close the bug too.

[Karl Dubost]

What about months?

2024-1-3

[Karl Dubost]

Pull request: https://github.com/WebKit/WebKit/pull/42306

[Karl Dubost]

Firefox, Chrome

Date.parse("2025-03-01T00:00:00Z")
1740787200000
Date.parse("2025-03-01T00:00:00")
1740754800000
Date.parse("2025-03-01")
1740787200000
Date.parse("2025-03-1")
1740754800000
Date.parse("2025-3-01")
1740754800000
Date.parse("2025-3-1")
1740754800000 
new Date("2025-03-01")
Sat Mar 01 2025 09:00:00 GMT+0900 (Japan Standard Time)
new Date("2025-03-1")
Sat Mar 01 2025 00:00:00 GMT+0900 (Japan Standard Time)


I just realized that 
Date.parse("2025-03-1") !== Date.parse("2025-03-01")

[Karl Dubost]

OK my patch is not working yet the same way that Firefox and Chrome are working. 
I wonder why they chose this implementation. 
It's quite problematic. 


> Date.parse("2025-03-01T00:00:00Z")
< 1740787200000

> Date.parse("2025-03-01T00:00:00")
< 1740754800000

> Date.parse("2025-03-01")
< 1740787200000

> Date.parse("2025-03-1")
< 1740787200000

> Date.parse("2025-3-01")
< 1740787200000

> Date.parse("2025-3-1")
< 1740787200000

> new Date("2025-03-01")
< Sat Mar 01 2025 09:00:00 GMT+0900 (Japan Standard Time)

> new Date("2025-03-1")
< Sat Mar 01 2025 09:00:00 GMT+0900 (Japan Standard Time)

> new Date("2025-3-1")
< Sat Mar 01 2025 09:00:00 GMT+0900 (Japan Standard Time)

> new Date("2025-3-01")
< Sat Mar 01 2025 09:00:00 GMT+0900 (Japan Standard Time)

[Karl Dubost]

More insanity 
https://codepen.io/webcompat/full/QwWOYjY

[Keita Nonaka]

Pull request: https://github.com/WebKit/WebKit/pull/49500

[EWS]

Committed 299182@main (82a3a3991176): <https://commits.webkit.org/299182@main>

Reviewed commits have been landed. Closing PR #49500 and removing active labels.