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

Issue 851487 link

Starred by 3 users
Status: Duplicate
Merged: issue 850876
Owner: ----
Closed: Jun 2018
Cc:
█ sindhu.chelamcherla@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

incorrect timezone offset for Europe/Kiev for winter dates below 1992

Reported by lsn...@gmail.com, Jun 11 2018 
UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36

Steps to reproduce the problem:
1. Be in Europe/Kiev
2. open a console
3. run "new Date(1972,0,24).getTimezoneOffset()" (without quotes)

What is the expected behavior?
Correct timezone offset for that day is -120

What went wrong?
It returns -180

Did this work before? Yes not sure when it broke, but works correctly in 49.0.2623.110. Likely a recent change

Chrome version: 67.0.3396.79  Channel: n/a
OS Version: 10
Flash Version: 

Incorrect behavior for all "winter" dates below 1992. 24th of January 1972 is just an example.

Europe/Kiev has DST for those years and "summer" timezone offsets for those years are correct.

The bug is probably in Chrome's tzdata or in how it's handled.

Comment 1 by lsn...@gmail.com, Jun 11 2018 

Chrome version 66.0.3359.181 also returns -120 correctly

Comment 2 by junov@chromium.org, Jun 11 2018

Components: -Blink Blink>HTML

Comment 3 by krajshree@chromium.org, Jun 12 2018

Labels: Needs-Bisect Needs-Triage-M67

Comment 4 by tkent@chromium.org, Jun 12 2018

Components: -Blink>HTML Blink>JavaScript

Comment 5 by sindhu.chelamcherla@chromium.org, Jun 12 2018

Cc: sindhu.chelamcherla@chromium.org
Labels: -Needs-Bisect Triaged-ET
Mergedinto: 850876
Status: Duplicate (was: Unconfirmed)
This issue looks similar to  issue 850876  and got same bisect range as that.

Good Build: 67.0.3389.0
Bad Build: 67.0.3390.0

Hence merging into it. Please feel free to raise a new issue if this is not same.

Thanks!

Comment 6 by lsn...@gmail.com, Jun 12 2018 

 Issue #850876  is marked as WontFix. This is unacceptable. This is obviously a regression in *this* case and it's actually pretty severe. It's severe enough that we are considering blocking users with Chrome 67 UserAgent from our web application, since they are sending the incorrect dates picked in datepickers, if those dates fall in the bugged interval (which is literally half of dates below 1991. Think dates of birth of half of people older than 27).

One hour difference from the incorrect timezone is a difference between 1972-01-24T00:00:00 and 1972-01-23T23:00:00.

If this comment isn't enough ground to reopen either this issue or the duplicate one, tell me and I'll raise a new one.

Comment 7 by jason.sa...@redskyit.com, Jun 14 2018 

I think the chrome devs will argue that -180 is correct because in 1972 Kiev did not observe daylight saving and therefore was 3 hours offset from UTC for the whole year.

See  issue 850951  comment 5.
►

Sign in to add a comment