Closed Bug 868496 Opened 7 years ago Closed 4 years ago

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

Categories

(Core :: JavaScript Engine, defect)

16 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1187233

People

(Reporter: hgezim, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [closeme 2016-04-17])

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.
Assignee: nobody → general
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
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
Blocks: 738511
Keywords: regression
Version: 20 Branch → 16 Branch
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.
`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
Duplicate of this bug: 911081
Assignee: general → nobody
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.
Flags: needinfo?(hgezim)
Whiteboard: [closeme 2016-04-17]
Fixed by bug 1187233
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(hgezim)
Resolution: --- → DUPLICATE
Duplicate of bug: 1187233
You need to log in before you can comment on or make changes to this bug.