WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/141044926
>
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 6
2024-12-08 17:38:24 PST
The code might be here.
https://searchfox.org/wubkat/rev/52d16c972a163b36fe64a99efb66af93c6e2f2b2/Source/WTF/wtf/DateMath.cpp#728-762
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
Pull request:
https://github.com/WebKit/WebKit/pull/42306
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
More insanity
https://codepen.io/webcompat/full/QwWOYjY
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug