[JSC] Relax Date.parse requirement
Created attachment 449721 [details] Patch
Created attachment 449724 [details] Patch
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 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.
Committed r288411 (246302@trunk): <https://commits.webkit.org/246302@trunk>
<rdar://problem/87931223>
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?
(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
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.
(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.
(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 ;)
*** Bug 238626 has been marked as a duplicate of this bug. ***