Bug 235468

Summary: [JSC] Relax Date.parse requirement
Product: WebKit Reporter: Yusuke Suzuki <ysuzuki>
Component: New BugsAssignee: Yusuke Suzuki <ysuzuki>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, cdumez, cmarcelo, darin, ews-watchlist, strarsis, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch darin: review+

Description Yusuke Suzuki 2022-01-21 21:28:07 PST
[JSC] Relax Date.parse requirement
Comment 1 Yusuke Suzuki 2022-01-21 21:30:32 PST
Created attachment 449721 [details]
Patch
Comment 2 Yusuke Suzuki 2022-01-21 22:16:33 PST
Created attachment 449724 [details]
Patch
Comment 3 Darin Adler 2022-01-22 13:49:36 PST
Comment on attachment 449724 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=449724&action=review

> Source/WTF/ChangeLog:12
> +        While the spec does not require accepting 't' / ' ' separator, ISO 8601 accepts it.
> +        This is because ECMA262's Date format is *not* ISO 8601 (it is called simplification
> +        of ISO 8601[1]).
> +        This patch relaxes this strictness to accept more formats, which can be accepted in
> +        the other engines too.

Is there some interoperability test suite we can add this to, in addition to having it in a WebKit-specific test?
Comment 4 Yusuke Suzuki 2022-01-22 15:48:41 PST
Comment on attachment 449724 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=449724&action=review

>> Source/WTF/ChangeLog:12
>> +        the other engines too.
> 
> Is there some interoperability test suite we can add this to, in addition to having it in a WebKit-specific test?

Unfortunately, there is no test like that. test262 has Date related tests, but it does not include this kind of things since it is not defined in the spec.
Comment 5 Yusuke Suzuki 2022-01-22 16:00:49 PST
Committed r288411 (246302@trunk): <https://commits.webkit.org/246302@trunk>
Comment 6 Radar WebKit Bug Importer 2022-01-22 16:01:17 PST
<rdar://problem/87931223>
Comment 7 Darin Adler 2022-01-22 16:23:44 PST
Since this matters for website compatibility, then we should strive to find a place for a test like this so we can come together with other web browser vendors to ensure interoperability.

If Test262 is not the place for it, maybe we can find another?
Comment 8 Yusuke Suzuki 2022-01-22 16:29:56 PST
(In reply to Darin Adler from comment #7)
> Since this matters for website compatibility, then we should strive to find
> a place for a test like this so we can come together with other web browser
> vendors to ensure interoperability.
> 
> If Test262 is not the place for it, maybe we can find another?

There is an attempt to specify the behavior in the spec[1].
So, if it is integrated into the spec, we can have a test in test262.
But so far, I have no idea where we can have this test since currently the spec says implementation-dependent...

[1]: https://github.com/tc39/proposal-uniform-interchange-date-parsing
Comment 9 Darin Adler 2022-01-22 16:56:40 PST
Makes sense that ideally we don’t want a test that doesn’t correspond to a specification. But I’d say that our core goal is the interoperability, so even if a particular specification leaves things undefined that need to be consistent achieve interoperability we’d want some kind of test.
Comment 10 Yusuke Suzuki 2022-01-22 17:44:09 PST
(In reply to Darin Adler from comment #9)
> Makes sense that ideally we don’t want a test that doesn’t correspond to a
> specification. But I’d say that our core goal is the interoperability, so
> even if a particular specification leaves things undefined that need to be
> consistent achieve interoperability we’d want some kind of test.

Since one of the goal of spec is interoperability, I think the right place is test262 after the proposal gets stage-3.
But right now it is not stage-3, so we cannot add tests to test262.
So, I think we should wait for the proposal getting mature enough to add tests.
Comment 11 Yusuke Suzuki 2022-01-22 17:45:37 PST
(In reply to Yusuke Suzuki from comment #10)
> (In reply to Darin Adler from comment #9)
> > Makes sense that ideally we don’t want a test that doesn’t correspond to a
> > specification. But I’d say that our core goal is the interoperability, so
> > even if a particular specification leaves things undefined that need to be
> > consistent achieve interoperability we’d want some kind of test.
> 
> Since one of the goal of spec is interoperability, I think the right place
> is test262 after the proposal gets stage-3.
> But right now it is not stage-3, so we cannot add tests to test262.
> So, I think we should wait for the proposal getting mature enough to add
> tests.

And until that, we can have these tests in WebKit tree as this patch added them ;)
Comment 12 Yusuke Suzuki 2022-04-06 03:23:40 PDT
*** Bug 238626 has been marked as a duplicate of this bug. ***