1188791 - Firefox for Windows Only does not respect United States DST rules prior to 2007

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[mariusz.pala]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36

Steps to reproduce:

Running the following JavaScript function:
  (new Date("03/15/1993")).toGMTString();







Actual results:

returns:
  "Mon, 15 Mar 1993 04:00:00 GMT"




Expected results:

when it should return:
  "Mon, 15 Mar 1993 05:00:00 GMT"

The rule changes are:
  Prior to 2007
    1st Sunday in April until Last Sunday in October
  After 2007
    2nd Sunday in March until 1st Sunday in November


This bug does not exist in Firefox on OSX. It is not present in IE10+ although it occurs in IE8 and Chrome as well (on Windows only).

Related:
https://stackoverflow.com/questions/8720579/windows-browser-dst-bug-prior-to-2007#

Comment 1

[Matt Johnson]

I wrote about this some time ago, and thought that it was already being worked on, but apparently not.
http://codeofmatt.com/2013/06/07/javascript-date-type-is-horribly-broken/

On my Windows machine in the Pacific time zone,
this code:  new Date(2004,10,7,0,0).toString()
returns:    "Sun Nov 07 2004 00:00:00 GMT-0700 (Pacific Daylight Time)"

In reality, DST ended in 2004 on November 4th, so this should have returned "GMT-0800 (Pacific Standard Time)"
http://www.timeanddate.com/time/zone/usa/los-angeles?year=2007

Note that ECMAScript 5 required in 15.9.1.8 to ignore past DST rules, which was ridiculous (IMHO).  Thankfully ECMAScript 6 removed that wording, and changed it in 20.3.1.8.

It was also clarified in EMCA-402 (Internationalization API) in 12.3.2 (1.0) and 12.3.4 (2.0) that the ES5 provision should be ignored.

So - why is Firefox still following the ES5 rule?

Comment 2

[Matt Johnson]

Sorry, my mistake above.  In 2004, DST ended even earlier, on October 31.
http://www.timeanddate.com/time/zone/usa/los-angeles?year=2004

Comment 3

[Jeff Walden [:Waldo]]

Lack of time to fix the problem, mostly.  (We might also be somewhat limited by our not shipping the Intl API everywhere, possibly making it hard to rely on ICU providing the necessary time zone data to fix the issue.)  There are many bugs to fix, and limited time to fix them.  We'll get to it eventually.

Comment 4

[Matt Johnson]

Well, I understand ICU is probably the best way, as a single source of tzdb time zone information across all platforms, but if you're currently using platform-specific APIs, then you could just use those APIs more efficiently.

I haven't dug into the Firefox code yet, but in Windows I'd guess you're currently using the GetTimeZoneInformation Win32 API, and instead you could use GetTimeZoneInformationForYear, or GetDynamicTimeZoneInformation, etc.  I'm sure there are similar APIs in other platforms.

Comment 5

[Matt Johnson]

If you want to point me at where the relevant code is, I'll take a closer look.  Sorry, I've not dug in to Firefox / Mozilla internals before.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

This is close to bug 1210093 and will probably be fixed once we fix bug 1201254