1335818 - Incorrect DST transition date for certain years in the Asia/Jerusalem time zone

Status: RESOLVED DUPLICATE of bug 1346211

(Core :: JavaScript: Internationalization API, defect, P3)

Description

[Matt Johnson]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

Jerusalem springs-forward on the Friday before the Last Sunday in March.   Chrome gets the date a week wrong for 2012, 2013, 2019 but not for other years.

The IANA TZ Database has the correct data, and so does the Windows registry, but somehow it is not coming through correctly.

Google Chrome appears to also get this wrong.  I think it may be an ICU bug, but I'm not sure.

See also: http://stackoverflow.com/a/41968750/634824

Thanks.

Steps to reproduce:

1. Set time zone to Jerusalem (Israel)
2. In Chrome JS console check the following:

console.log(new Date(2013, 2, 22, 1, 0, 0, 0).toString());
console.log(new Date(2013, 2, 22, 2, 0, 0, 0).toString());
console.log(new Date(2013, 2, 22, 3, 0, 0, 0).toString());
console.log(new Date(2013, 2, 29, 1, 0, 0, 0).toString());
console.log(new Date(2013, 2, 29, 2, 0, 0, 0).toString());
console.log(new Date(2013, 2, 29, 3, 0, 0, 0).toString());


Actual results:


Fri Mar 22 2013 01:00:00 GMT+0200 (Jerusalem Standard Time)
Fri Mar 22 2013 03:00:00 GMT+0300 (Jerusalem Daylight Time)
Fri Mar 22 2013 03:00:00 GMT+0300 (Jerusalem Daylight Time)
Fri Mar 29 2013 01:00:00 GMT+0300 (Jerusalem Daylight Time)
Fri Mar 29 2013 02:00:00 GMT+0300 (Jerusalem Daylight Time)
Fri Mar 29 2013 03:00:00 GMT+0300 (Jerusalem Daylight Time)


Expected results:


Fri Mar 22 2013 01:00:00 GMT+0200 (Jerusalem Standard Time)
Fri Mar 22 2013 02:00:00 GMT+0200 (Jerusalem Standard Time)
Fri Mar 22 2013 03:00:00 GMT+0200 (Jerusalem Standard Time)
Fri Mar 29 2013 01:00:00 GMT+0200 (Jerusalem Standard Time)
Fri Mar 29 2013 03:00:00 GMT+0300 (Jerusalem Daylight Time)
Fri Mar 29 2013 03:00:00 GMT+0300 (Jerusalem Daylight Time)

Comment 1

[André Bargull [:anba]]

ICU isn't at fault here, because we aren't actually using ICU to retrieve time zone information outside of Intl.DateTimeFormat methods. (Maybe we should use ICU to avoid bugs like this one, but we first need to enable ICU on every supported platform.) 

So, there are at least two bugs in play. First bug 830304, when the patch from that bug is applied, I get the expected results on Ubuntu 16.04:

Fri Mar 22 2013 01:00:00 GMT+0200 (IST)
Fri Mar 22 2013 02:00:00 GMT+0200 (IST)
Fri Mar 22 2013 03:00:00 GMT+0200 (IST)
Fri Mar 29 2013 01:00:00 GMT+0200 (IST)
Fri Mar 29 2013 03:00:00 GMT+0300 (IDT)
Fri Mar 29 2013 03:00:00 GMT+0300 (IDT)


On Win10, the DST change is applied one week too early. This issue could be similar to bug 1330307 (localtime_s is returning an incorrect result), but for now this is just a guess:

Fri Mar 22 2013 01:00:00 GMT+0200 (Jerusalem Standard Time)
Fri Mar 22 2013 03:00:00 GMT+0300 (Jerusalem Daylight Time)
Fri Mar 22 2013 03:00:00 GMT+0300 (Jerusalem Daylight Time)
Fri Mar 29 2013 01:00:00 GMT+0300 (Jerusalem Daylight Time)
Fri Mar 29 2013 02:00:00 GMT+0300 (Jerusalem Daylight Time)
Fri Mar 29 2013 03:00:00 GMT+0300 (Jerusalem Daylight Time)

Comment 2

[Matt Johnson]

Thanks.  Good to know it's not ICU, but also then it's strange that Chrome is also affected, but Edge is not.  Maybe just an easy bug to make?  IDK.

On Linux, the IANA data is simply Fri>=23, which is easy enough to implement.  On Windows, the tz data gives a 5 in the wDay field of the SYSTEMTIME object, which is supposed to be interpreted as "last", but it seems to be being interpreted as "fourth".

Sorry, not familiar with FF internals, but if the code is OSS - point me at the relevant code path and I'll see if I can spot the bug.

Also note that ECMAScript is currently ambiguous as to which way to adjust invalid/ambiguous local time values, and that FF is currently opposite what Chrome and others are doing.  This is being standardized here: https://github.com/tc39/ecma262/pull/778.  FF will need to adjust but that's a separate issue. :)

Comment 3

[Matt Johnson]

Ok, I dug in a bit on my own and found in js/src/vm/DateTime.cpp that it uses the localtime_s function on Windows.  Looks like you already foundt that in https://bugzilla.mozilla.org/show_bug.cgi?id=1330307.  :)

So basically, this function only uses the *current year's* DST rules only.  Since 2017 rules for this zone use the 4th Friday of the month, we get the 4th Friday applied to other years as well.

Essentially, it acts the same as the FileTimeToLocalFileTime function in the Win32 API, which warns against this problem.  Instead, one is supposed to jump through the hoops of FileTimeToSystemTime, SystemTimeToTzSpecificLocalTime(Ex), SystemTimeToFileTime.... Or I suppose one could go over to the SystemTimeToTzSpecificLocalTime function... Yes, these APIs are a bit ridiculous, but the point is that you have to somehow take into account the DST rule that applies in the year in question - not the current year.

I'm not sure if there's a std C equivalent for this.  But it does explain a few things.

Comment 4

[André Bargull [:anba]]

(In reply to Matt Johnson from comment #3)
> I'm not sure if there's a std C equivalent for this.  But it does explain a
> few things.

Wow, nice sleuthing. That really does explain a few of the Windows time zone problems I've seen over the last years!

Comment 5

[André Bargull [:anba]]

Dup'ing forward to bug 1346211 which should have fixed this problem. Please reopen if the issue is still present. Thanks!