Javascript Date DST start for E. south america in 2017 incorrect
Reported by
bish...@gmail.com,
Apr 12 2016
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36 Steps to reproduce the problem: Windows OS time zone is set to Brasilia. Javascript date var set to Oct 15 2017 shows time zone as GMT -3 hrs E. South America. What is the expected behavior? Expected time zone is GMT -2 hrs (as Oct 15 2017 is the DST start date for Brazil (Brasilia) time zone) What went wrong? DST for E. South America time zone is not set correctly Did this work before? N/A Chrome version: 49.0.2623.110 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 21.0 r0 Searched for other bugs related to Brazil DST and found 425434
,
Apr 14 2016
,
Sep 29 2016
It appears that for chrome the date of DST starts form Brazil is 2017-10-23, but the right date is 2017-10-15.
Running 'new Date("2017-10-15T00:00:00.0000000-03:00").getTimezoneOffset()' returns 180 which is wrong, because in that date we are on BRST and the value should be 120.
Running 'new Date("2017-10-15T01:00:00.0000000-02:00").getTimezoneOffset()' returns 180 which is wrong, because in that date we are on BRST and the value should be 120.
Running 'new Date("2017-10-16T00:00:00.0000000-02:00").getTimezoneOffset()' also returns 180 but should return 120 for BRST.
Only when running 'new Date("2017-10-23T00:00:00.0000000-02:00").getTimezoneOffset()' returns 120 which is right for BRST.
,
Sep 29 2016
,
Feb 20 2017
toLocaleString() and Intl.DateTimeFormat() work fine.
new Date("2017-10-15T12:00Z").toLocaleString("en", {'timeZone': 'America/Sao_Paulo'})
"10/15/2017, 10:00:00 AM"
new Date("2017-10-14T12:00Z").toLocaleString("en", {'timeZone': 'America/Sao_Paulo'})
"10/14/2017, 9:00:00 AM"
Using ICU for Date.* will fix this. Blocked by bug v8:3547
,
Jul 14 2017
,
Jul 20 2017
,
Jul 20 2017
,
Mar 8 2018
Actually, bug v8:3547 should not matter. bug v8:6031 should fix this issue. https://www.timeanddate.com/time/change/brazil/brasilia?year=2017 In America/Sao_Paulo, new Date("2018-11-03T12:00Z").getTimezoneOffset() should return 180. new Date("2018-11-04T12:00Z").getTimezoneOffset() should return 120. With ToT chrome (with IANA timezone database updated and bug v8:6031 fixed), the above should be fine. I'll mark this as fixed after trying it out. I don't think this issue is blocked by bug v8:3547 .
,
Mar 8 2018
See https://www.timeanddate.com/time/zone/brazil/brasilia for the DST start/end for Brasilia. * Chrome without icu-timezone-data and Firefox new Date("2017-10-15T12:00Z").getTimezoneOffset() 180 <====== should be 120 new Date("2017-10-14T12:00Z").getTimezoneOffset() 180 new Date("2017-10-23T12:00Z").getTimezoneOffset() 120 * Chrome with icu-timezone-data and IE 11 new Date("2017-10-15T12:00Z").getTimezoneOffset() 120 new Date("2017-10-14T12:00Z").getTimezoneOffset() 180 * Chrome without icu-timezone-data, Firefox and IE 11 new Date("2018-11-03T12:00Z").getTimezoneOffset() 120 <== should be 180 new Date("2018-11-04T12:00Z").getTimezoneOffset() 120 * Chrome with icu-timezone-data new Date("2018-11-03T12:00Z").getTimezoneOffset() 180 new Date("2018-11-04T12:00Z").getTimezoneOffset() 120 So, with icu-timezone-data turned ON in bug v8:6031 , this is also fixed.
,
Apr 10 2018
Issue 819686 has been merged into this issue. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by b...@chromium.org
, Apr 12 2016