Bug 235468 – [JSC] Relax Date.parse requirement

• Component: New Bugs
• Status: RESOLVED FIXED

[Yusuke Suzuki]

[JSC] Relax Date.parse requirement

[Yusuke Suzuki]

Created attachment 449721 [details]
Patch

[Yusuke Suzuki]

Created attachment 449724 [details]
Patch

[Darin Adler]

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?

[Yusuke Suzuki]

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.

[Yusuke Suzuki]

Committed r288411 (246302@trunk): <https://commits.webkit.org/246302@trunk>

[Radar WebKit Bug Importer]

<rdar://problem/87931223>

[Darin Adler]

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?

[Yusuke Suzuki]

(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

[Darin Adler]

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.

[Yusuke Suzuki]

(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.

[Yusuke Suzuki]

(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 ;)

[Yusuke Suzuki]

*** Bug 238626 has been marked as a duplicate of this bug. ***