New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 687751 link

Starred by 4 users

Issue metadata

Status: Duplicate
Merged: issue v8:5714
Owner: ----
Closed: Jan 4
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

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

Reported by mj1...@gmail.com, Feb 1 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36

Steps to reproduce the problem:
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());

What is the expected behavior?
Should emit:

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)

What went wrong?
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)

Did this work before? N/A 

Chrome version: 56.0.2924.76 Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 24.0 r0

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.

FireFox 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.
 
Components: -Blink Blink>JavaScript>Internationalization
Labels: Needs-Bisect Prestable-56.0.2924.76 Needs-Triage-M56

Comment 3 by mj1...@gmail.com, Feb 2 2017

Ok, not an ICU bug (I think).  But rather that localtime_s is being used on Windows, which only takes the current DST rule into account.  It needs to instead use one of the Win32 APIs that understands Windows year-over-year dynamic DST changes, such as SystemTimeToTzSpecificLocalTime.
Labels: Hotlist-Interop
Status: Untriaged (was: Unconfirmed)
Confirmed on Windows 7.

Emits something closer to (but not exactly like) the expected results using Internet Explorer 11 -
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 01:00:00 GMT+0200 (Jerusalem Standard Time) // This is different
Fri Mar 29 2013 03:00:00 GMT+0300 (Jerusalem Daylight Time)

And something closer to (but not exactly like) the actual results using Firefox 50 -
Fri Mar 22 2013 01:00:00 GMT+0200 (Jerusalem Standard Time)
Fri Mar 22 2013 01:00:00 GMT+0200 (Jerusalem Standard Time) // This is different
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 5 by phistuck@gmail.com, Feb 2 2017

Though I am not sure about correctness of the expected results (twice 3:00?).
Cc: littledan@chromium.org
Status: Available (was: Untriaged)
Cc: rbasuvula@chromium.org
Labels: -Needs-Bisect -Needs-Triage-M56 M-58
Tested the issue on chrome Stable #57.0.2924.76, Canary 58.0.3000.0 in Windows 7 and was able to reproduce the issue.

Observations: This issue is behaving differently from M30-M58 versions.Please find the screen shot for reference.

This is a Non-Regression issue since seeing this from M30 #30.0.1549.0.

Note : Not Able to reproduce the issue in MAC 10.12 and Linux Ubuntu 14.04.

Thank you.
687751.png
412 KB View Download
 Issue 689258  has been merged into this issue.
I was able to reproduce this issue as well on Version 62.0.3202.75 (Official Build) (64-bit) using future date:
(new Date(2019,3,23)).toString()
Tue Apr 23 2019 00:00:00 GMT+0300 (Jerusalem Daylight Time)

Where GMT difference should be +0200 at that date (DST is being changed only on March 29th, 2019).
Project Member

Comment 10 by sheriffbot@chromium.org, Nov 2

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Available (was: Untriaged)
Mergedinto: v8:5714
Status: Duplicate (was: Available)
This was fixed a while ago when v8 switched to use ICU for timezone data. 


Sign in to add a comment