283825 2024-11-29 06:10:20 -0800 non standard new Date('2024-12-3') yields to Invalid Date 2025-08-26 18:34:14 -0700 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build All All RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=241103 https://bugs.webkit.org/show_bug.cgi?id=223166 BrowserCompat, InRadar P2 Normal --- 1 buzzdee iKonnyaku40 buzzdee karlcow rechdshraipfelehr webkit-bug-importer oldest_to_newest 2078164 0 buzzdee 2024-11-29 06:10:20 -0800 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 2078393 1 karlcow 2024-12-01 19:19:58 -0800 > 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? 2078394 2 karlcow 2024-12-01 19:20:56 -0800 The valid format per spec is `YYYY-MM-DDTHH:mm:ss.sssZ` or a truncation of it. 2078501 3 buzzdee 2024-12-02 07:13:43 -0800 > 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. 2079630 4 webkit-bug-importer 2024-12-06 06:11:13 -0800 <rdar://problem/141044926> 2080031 5 karlcow 2024-12-08 17:29:24 -0800 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. 2080041 6 karlcow 2024-12-08 17:38:24 -0800 The code might be here. https://searchfox.org/wubkat/rev/52d16c972a163b36fe64a99efb66af93c6e2f2b2/Source/WTF/wtf/DateMath.cpp#728-762 2080042 7 karlcow 2024-12-08 17:39:51 -0800 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 2080043 8 karlcow 2024-12-08 17:44:33 -0800 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 2102198 9 rechdshraipfelehr 2025-03-11 05:59:47 -0700 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 2102435 10 karlcow 2025-03-11 19:41:05 -0700 > 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. 2102437 11 karlcow 2025-03-11 19:47:13 -0700 What about months? 2024-1-3 2102468 12 karlcow 2025-03-11 21:49:08 -0700 Pull request: https://github.com/WebKit/WebKit/pull/42306 2102875 13 karlcow 2025-03-13 05:27:09 -0700 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") 2102877 14 karlcow 2025-03-13 05:36:44 -0700 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) 2103679 15 karlcow 2025-03-16 19:19:01 -0700 More insanity https://codepen.io/webcompat/full/QwWOYjY 2136996 16 iKonnyaku40 2025-08-16 12:38:49 -0700 Pull request: https://github.com/WebKit/WebKit/pull/49500 2138950 17 ews-feeder 2025-08-26 18:34:12 -0700 Committed 299182@main (82a3a3991176): <https://commits.webkit.org/299182@main> Reviewed commits have been landed. Closing PR #49500 and removing active labels.