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.
Created attachment 341111 [details] Patch
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.
Committed r232122: <https://trac.webkit.org/changeset/232122>
<rdar://problem/40495678>