Issue metadata
Sign in to add a comment
|
incorrect timezone offset for Europe/Kiev for winter dates before 1991
Reported by
lsn...@gmail.com,
Jun 13 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: 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 That's the value reported in any other software What went wrong? It returns -180 Did this work before? Yes 66.0.3359.181 Chrome version: 67.0.3396.79 Channel: n/a OS Version: 10 Flash Version: Incorrect behavior for all "winter" dates before 1991. 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 how Chrome's tzdata is handled. This is reraising of the issue 851487 , as I was told to do there. I don't seem to have other options to reopen 851487. In there it was determined that: Good Build: 67.0.3389.0 Bad Build: 67.0.3390.0 That issue was marked as a duplicate of issue 850876 , which is marked as WontFix. This is unacceptable. This is obviously a regression in *this* case. The issue is 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 for half of the people about 27 years old and older). One hour difference from the incorrect timezone is a difference between 1972-01-24T00:00:00 and 1972-01-23T23:00:00.
,
Jun 13 2018
,
Jun 14 2018
This issue looks similar to issue 850876 , hence merged original issue 851487 to 850876. But user raised a new issue 852321 . Hence providing bisect results and assigning to appropriate owner. Able to reproduce the issue on reported version 67.0.3396.79 and latest chrome 69.0.3457.0 using Mac 10.13.3, Ubuntu 14.04 and Windows-10, hence providing Bisect Info Bisect Info: ================ Good build: 67.0.3389.0 Bad build: 67.0.3390.0 You are probably looking for a change made after 548395 (known good), but no later than 548396 (first known bad). https://chromium.googlesource.com/chromium/src/+log/f42b19bde0ce6e2d52fadc34a19b005dc236c2b8..7bed949c66408be72fa74397b34ddb0835b12df9 Suspecting: https://chromium.googlesource.com/v8/v8/+/1d3a87bd1cf456c005a4e5dbdb6f65e6b738ea91 from above changelog Reviewed-on: https://chromium-review.googlesource.com/572148 @Jungshik Shin: Please confirm the bug and help in triaging this bug based on inputs in comment#0. Adding RB-Stable, please remove if not applicable. Thanks!
,
Jun 14 2018
In 1972, Kiev timezone was UTC+3 year-round. See https://www.timeanddate.com/time/zone/ukraine/kyiv and select 1970 - 1979.
,
Jun 14 2018
,
Jun 14 2018
In case it's not clear. This is WAI(working-as-intended) and per spec.
,
Jun 14 2018
Okay, I am sorry to not have thoroughly studied this before submitting the issue then. I've now looked into the history of time in my city and so far it looks like you are correct. So if it was "wrong" in the previous version... That then raises the question, why is the timezone offset incorrect in all other browsers and the backend handling the user-submitted dates. I've just looked into tzdata and I don't see a 1980 point there, when the DST was introduced here. So is tzdata wrong? Everything just became even more confusing.
,
Jun 18 2018
Issue 853124 has been merged into this issue.
,
Jun 18 2018
Issue 853463 has been merged into this issue.
,
Jun 20 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tkent@chromium.org
, Jun 13 2018