Bug 185868 – Date.parse() doesn't properly handle input outside of ES Spec limits

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Michael Saboff]

From May 2018 TC-39 meeting:

SpiderMonkey strictly conforms to the Time Value specification:
> Date.parse("-271821-04-19T11:59:59.999Z")
NaN
V8, JSC:
> Date.parse("-271821-04-19T11:59:59.999Z")
-8640000043200001

> Date.parse("-999999-01-01T00:00:00.000Z")
V8/JSC	-31619087596800000
> Date.parse("-999999-01-01T00:00:00.001Z")
V8/JSC	-31619087596800000
> Date.parse("-999999-01-01T00:00:00.002Z")
V8		-31619087596800000
JSC		-31619087596799996

> Date.parse("-1000000-01-01T00:00:00.000Z")
V8		NaN
> Date.parse("-1000000-01-01T00:00:00.000Z")
JSC		-31619119219200000

Apparently the Safari implementation is accepting any year value from MIN_INT to MAX_INT - 1:
> Date.parse("-2147483648-01-01T00:00:00.000Z")
NaN
> Date.parse("-2147483647-01-01T00:00:00.000Z")
-67768100536348800000
...
> Date.parse("2147483646-01-01T00:00:00.000Z")
67767976170460800000
> Date.parse("2147483647-01-01T00:00:00.000Z")
NaN

Test262 tests will land soon.

[Michael Saboff]

Created attachment 341111 [details]
Patch

[Mark Lam]

Comment on attachment 341111 [details]
Patch

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

r=me

> Source/WTF/wtf/DateMath.cpp:562
> +    // Clamp to EcmaScript standard of +/- 100,000,000 days from 01 January, 1970.

Let's add a link to https://tc39.github.io/ecma262/#sec-time-values-and-time-range here.

[Michael Saboff]

Committed r232122: <https://trac.webkit.org/changeset/232122>

[Radar WebKit Bug Importer]

<rdar://problem/40495678>