NEW 283825
non standard new Date('2024-12-3') yields to Invalid Date
https://bugs.webkit.org/show_bug.cgi?id=283825
Summary non standard new Date('2024-12-3') yields to Invalid Date
Sebastian Schlatow
Reported 2024-11-29 06:10:20 PST
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
Attachments
Karl Dubost
Comment 1 2024-12-01 19:19:58 PST
> 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
Comment 2 2024-12-01 19:20:56 PST
The valid format per spec is `YYYY-MM-DDTHH:mm:ss.sssZ` or a truncation of it.
Sebastian Schlatow
Comment 3 2024-12-02 07:13:43 PST
> 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
Comment 4 2024-12-06 06:11:13 PST
Karl Dubost
Comment 5 2024-12-08 17:29:24 PST
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
Comment 7 2024-12-08 17:39:51 PST
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
Comment 8 2024-12-08 17:44:33 PST
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
rechdshraipfelehr
Comment 9 2025-03-11 05:59:47 PDT
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
Comment 10 2025-03-11 19:41:05 PDT
> 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
Comment 11 2025-03-11 19:47:13 PDT
What about months? 2024-1-3
Karl Dubost
Comment 12 2025-03-11 21:49:08 PDT
Karl Dubost
Comment 13 2025-03-13 05:27:09 PDT
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
Comment 14 2025-03-13 05:36:44 PDT
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
Comment 15 2025-03-16 19:19:01 PDT
Note You need to log in before you can comment on or make changes to this bug.