2

I get TZ difference on windows 10 between Chrome and Edge. When I run this code in the console:

> var date = new Date(2013, 2, 29, 1, 0, 0, 0);
> date

This will be the output when running in on Edge

> [date] Fri Mar 29 2013 01:00:00 GMT+0200 (Jerusalem Standard Time)

While This will be the output on Chrome:

> [date] Fri Mar 29 2013 01:00:00 GMT+0300 (Jerusalem Daylight Time)

It seems that in Chrome it is recognise as DST but in Edge it doesn’t, which is correct.
(Attached screenshot)

If I turn off the “Adjust for day light saving time automatically” configuration - Chrome date becomes the same. (image2)

Someone, can explain why? and how to get the correct TZ in chrome in any "Date and Time" configuration?

Edge version: 20.10240.16384.0 Chrome version: 56.0.2924.75 (64-bit)

TylerH
  • 20,799
  • 66
  • 75
  • 101
Noam antebi
  • 271
  • 2
  • 9

1 Answers1

2

This indeed appears to be a bug.

The TZ Database shows:

# As of 2013, DST starts at 02:00 on the Friday before the last Sunday
# in March.  DST ends at 02:00 on the last Sunday of October.

# Rule  NAME  FROM  TO   TYPE  IN   ON       AT    SAVE  LETTER/S
Rule    Zion  2013  max  -     Mar  Fri>=23  2:00  1:00  D
Rule    Zion  2013  max  -     Oct  lastSun  2:00  0     S

# Zone    NAME            GMTOFF    RULES   FORMAT  [UNTIL]
Zone    Asia/Jerusalem    2:20:54   -       LMT     1880
                          2:20:40   -       JMT     1918    # Jerusalem Mean Time?
                          2:00      Zion    I%sT

Therefore, in 2013, DST should have started on the Friday before the last Sunday in March, which was March 29. (The previous Friday was March 22, which doesn't meet the Fri>=23 rule in the time zone data.) This is date is also corroborated by timeanddate.com.

Windows appears to have this data correct. Examining the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Israel Standard Time\Dynamic DST

Windows Registry

The last part I highlighted in green is the DST start date.

00 00 = Year        (ignored)
03 00 = Month       (March)
05 00 = Day of week (Friday)
05 00 = Day number  (5 = last)
02 00 = Hour        (02:00)
00 00 = Minute
00 00 = Second
00 00 = Millisecond

So both the Windows and the IANA data are pointing at the same date. Yet somehow Chrome is getting it wrong.

Chrome Screenshot

I also tested FireFox, which also appears to be getting it wrong:

FireFox Screenshot

I can also reproduce these results in Node.js.

But yes, Edge is getting it correct:

Edge Screenshot

Do note that the browsers also differ in which direction they adjust a local time that falls into the "gap" created by the spring-forward transition. This is expected, and is being worked on in for a future version the of ECMAScript spec.

I don't work on the actual implementation within these browsers, but my understanding is that both Chrome, Node, and FireFox rely on ICU for their time zone internals. My guess is that it is an ICU bug that is being exposed here. Update: It appears to be a bug in the Microsoft C/C++ Runtime. I'm working on getting it to the right folks.

As far as what to do about it - if accurate historical time zone data is essential to your application, I strongly suggest you not rely on the environment to provide it, but bring it yourself using one of the libraries I listed here, such as moment-timezone (which I help maintain).

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • Thanks @MattJohnson for the detailed answer! Two comments: 1. Should we open a bug for Chrome and FF? 2. The specific date I tested wasn't a random one. It is used by this [library](https://github.com/HenningM/jstimezonedetect). I'll mention this issue also there – Noam antebi Feb 01 '17 at 09:05
  • 1
    Chrome bug reported [here](https://bugs.chromium.org/p/chromium/issues/detail?id=687751), FireFox bug reported [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1335818). Thanks! – Matt Johnson-Pint Feb 02 '17 at 00:06