868496 - Passing date object that represents the minimum date into new Date() creates an invalid date

Status: RESOLVED DUPLICATE of bug 1187233

(Core :: JavaScript Engine, defect)

Description

[Gezim Hoxha]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31

Steps to reproduce:

Created a new Date object with another date object as the first parameter. The date object I passed in represents the minimum date (for my case Sun Dec 31 0000 17:00:00 GMT-0700 (Mountain Standard Time)).

Here's a scratch pad paste:

minDate = new Date(-62135596800000)
/*
Sun Dec 31 0000 17:00:00 GMT-0700 (Mountain Standard Time)
*/

new Date(minDate)
/*
Invalid Date
*/



Actual results:

The new date object has an Invalid Date.


Expected results:

It should have essentially create or even return a copy of the object I passed in.

Comment 1

[Loic]

Maybe a dupe.

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5891cc95eac7&tochange=95d1bb200f4e

Suspected bug:
martenschilstra — Bug 738511 - new Date(value) should call ToPrimitive on value before testing for string-ness. r=jwalden

Comment 2

[Jeff Walden [:Waldo]]

new Date(otherDate) is not an exact clone, in ES5.  By default it's a conversion to string, then creation of a date from that.  This strips off milliseconds, and it probably has boundary condition issues that cause this bug.  (Possibly depending on your time zone.)  There was some movement to make ES6 special-case new Date(Date object) to do an exact clone; I'm not sure what the latest is there, but if they've made that change, our making it as well would address this issue.

Comment 3

[André Bargull [:anba]]

`Date.parse()` (which is used internally in Date's [[Construct]] logic) just doesn't work properly for all date-time strings returned by Date.prototype.toString(). ES5.1, 15.9.4.2, defines some round-trip conditions, but those aren't completely implemented in the common JS engines. 

For example in SpiderMonkey, dates with years before "70" are not accepted, years after "70" are interpreted as 1900 + year: 

js> Date.parse((d = new Date(0), d.setFullYear(0), d.toString()))
NaN
js> Date.parse((d = new Date(0), d.setFullYear(69), d.toString()))
NaN
js> Date.parse((d = new Date(0), d.setFullYear(70), d.toString()))
0

Comment 5

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Firefox: 45.0, Build ID: 20160303134406
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0

Hi Gezim,

I have tested this issue on the latest Firefox (45.0) release, latest Nightly (48.a01 Build ID: 20160316030233) build, but I could not reproduce it. I have tested this using the code provided in bug 911081 which is duplicate of this bug. I have also tested this on Firefox 16.0, and I was able to reproduce it. It seems that the issue was fixed.

Is this still reproducible on your end ? If yes, can you please retest this using latest Firefox release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E). 

Thanks,
Cosmin.

Comment 6

[Loic]

Fixed by bug 1187233