See https://github.com/es-shims/es5-shim/issues/329 `new Date(1970, 0, 1,0, 0, 0, 2147483647);` produces a valid Date object, `new Date(1970, 0, 1,0, 0, 0, 2147483648);` does not. 2147483648 is, of course, `Math.pow(2, 31)`. So, the issue seems to be that Safari 8 and 9 - alone amongst the browsers, it's worth noting - is treating the millisecond parameter to `Date` as a signed 32-bit integer - when in fact, it should allow all integer values up to `Number.MAX_SAFE_INTEGER`: ie, a 64-bit signed integer, also known as a normal JS number value. This does not appear to be an issue for the other parameters to the 7-arg form of the Date constructor, but when fixing this, please verify that all JS Number values work as expected when passed in as any of the 7 arguments.
Note that Number.MAX_SAFE_INTEGER is 53 bits, not 64, since only 53 bits of precision fit into a double.
Ah, right - in that case, despite not all integers being safe in [53,64] bits, it should still support any 64-bit signed integer.
The Date constructor code already treats the millisecond parameter as a double rather than an integer to avoid the 32-bit integer clamping problems. The problem is simply in the input validation. Here is the code validating the seventh argument in the millisecondsFromComponents function in DateConstructor.cpp: !std::isfinite(doubleArguments[6]) || (doubleArguments[6] > INT_MAX) || (doubleArguments[6] < INT_MIN) As you can see, it’s incorrectly comparing with 32 bit integer minimums and maximums; that’s where the bug comes from. (The code has no business using INT_MIN and INT_MAX for 32-bit integer range checking anyway.) The fix will be to write a corrected version of this range checking or possibly to remove it entirely. Someone just needs to figure out what the limits need to be. The “any 64-bit signed integer” idea isn’t compatible with JavaScript’s usual type model; integer values are typically treated as a subset of double values rather than a distinct type with values not representable as doubles. Seems highly unlikely that is required, and equally unlikely that it is supported in other JavaScript engines. If this does turn out to be required, there will be substantial design and implementation work required to resolve this and it won’t just be a simple bug fix. To make it easy to fix the bug we need a test case that covers the values as the limits of what are allowed for Date, and it would be worthwhile to both try the test cases on other browsers and perhaps make it part of an ES6 test suite.
I tried just removing the INT_MAX and INT_MIN comparisons and it wasn't quite enough because some of our lower level date code uses int internally, and the upgrade to double is non-trivial.