Closed Bug 1029923 Opened 10 years ago Closed 7 years ago

ES5 15.9.1.8 daylight savings year remapping breaks Date for US users in 2041, 2047, etc.

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1406993

People

(Reporter: andrew, Unassigned)

Details

(Whiteboard: [parity-v8])

This bug actually bit me in production when a user was attempting to enter a date for a parameter related to bond pricing which happened to be 7-Jan-2047 and it wound up reverting to 6-Jan-2047 when being processed in JS.

Spidermonkey's "jsdate" implementation follows the loosey-goosey ES5 15.9.1.8 spec and maps all far past/future years to an equivalent (but not) year for the purposes of calculating DST. (Note: This part of the spec was already cleaned up in ES6 to use the actual IANA tzdata so that this bug won't occur)

2047 happens to re-map to 1974, and in the US in 1974:

"On January 4, 1974, President Nixon signed into law the Emergency Daylight Saving Time Energy Conservation Act of 1973. Then, beginning on January 6, 1974, implementing the Daylight Saving Time Energy Act, clocks were set ahead. On October 5, 1974, Congress amended the Act, and Standard Time returned on October 27, 1974. Daylight Saving Time resumed on February 23, 1975 and ended on October 26, 1975."

Future years break in current released Firefox and do not break in current released Chrome:

Chrome 35.0.1916.153:
> (new Date(2047, 0, 7)).toString()
"Mon Jan 07 2047 00:00:00 GMT-0800 (PST)"

Firefox 30.0: 
> (new Date(2047, 0, 7)).toString()
"Mon Jan 07 2047 00:00:00 GMT-0700 (PST)" <-- -7 offset!

I'm filing this to just point out that production applications do use dates this far in the future and current released Firefox does not handle them appropriately. Will the move to tzdata happen sometime soon due to ES6 work?
(I am removing the remapping because we already embed atop tzdata -- this is just more of a heads up since Firefox behavior differs from Chrome)
Just FYI: Bug 351066, comment #20 gives an overview over the different equivalent year rules in Firefox, Chrome and WebKit.
Whiteboard: [parity-v8]
This specific issue was fixed in bug 1406993.

Related issues:
bug 1406992 explores using 64-bit time_t if supported by the OS. And bug 1346211 tracks using ICU for all date/time conversions.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.