Issue metadata
Sign in to add a comment
|
Chrome Beta Browser timezone offsets are wrong |
||||||||||||||||||||||||
Issue description
NOTE: This bug will be restricted to Google employees only, however, please *do not* include links to prod infrastructure (e.g. Borg cells) in these reports.
Version: chrome-beta-linux (67.0.3396.18)
OS: Linux
What steps will reproduce the problem?
1. I'm uncertain how to get chrome-beta on my workstation so all of my exposure to this is via blaze tests. My javascript tests are succeeding on all browsers except chrome-linux-beta (normal chrome-linux is fine). I simplified my failure down and got this example:
let stringified = "";
for (let a = 0; a <= 50; a++) {
const Jan_01_1900 = -2208988800000;
const year = 365 * 24 * 60 * 60 * 1000;
const millis = Jan_01_1900 - (a * year);
stringified += "\n" + millis + ": " + new Date(millis);
}
assertEquals("", stringified);
The resulting failure lists 50 years of dates but something odd happens between 1884 and 1883... the PST time zone loses 7 minutes, 58 seconds (and maybe an undisplayed number of ms).
-2650492800000: Sun Jan 03 1886 16:00:00 GMT-0800 (Pacific Standard Time)
-2682028800000: Sat Jan 03 1885 16:00:00 GMT-0800 (Pacific Standard Time)
-2713564800000: Fri Jan 04 1884 16:00:00 GMT-0800 (Pacific Standard Time)
-2745100800000: Thu Jan 04 1883 16:07:02 GMT-0752 (Pacific Standard Time)
-2776636800000: Wed Jan 04 1882 16:07:02 GMT-0752 (Pacific Standard Time)
-2808172800000: Tue Jan 04 1881 16:07:02 GMT-0752 (Pacific Standard Time)
Further investigation indicates this happens on November 17->18th:
-2717539200000: Mon Nov 19 1883 16:00:00 GMT-0800 (Pacific Standard Time)
-2717625600000: Sun Nov 18 1883 16:00:00 GMT-0800 (Pacific Standard Time)
-2717712000000: Sat Nov 17 1883 16:07:02 GMT-0752 (Pacific Standard Time)
-2717798400000: Fri Nov 16 1883 16:07:02 GMT-0752 (Pacific Standard Time)
,
May 31 2018
I am uncertain exactly what you mean by that. Could you provide me with an example?
If not, you could literally just use javascript like this:
const a = new Date("January 1 1850, PST");
assertEquals(480 /* 8 hours */, a.getTimezoneOffset());
In Chrome-Beta-Linux the offset is inaccurately set to 472.something
,
May 31 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 1 2018
,
Jun 4 2018
@tearseb: Could you please help us with a sample file or URL where you're seeing this issue to check from our end? Thanks!!
,
Jun 4 2018
No, I can't submit tests that fail so there's no url or sample file.
The simplest way to repro this is to get a copy of Chrome-Beta, bring up a blank page, hit f12 and get into the console. Then type two javascript commands:
const a = new Date("January 1 1850, PST");
console.log(a.getTimezoneOffset());
You should get 480 (8 hours of offset) and instead you get 472.
,
Jun 4 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 11 2018
The timezone offset has changed over time. For this particular issue, the offset before the introduction of the standard timezone in North America was different from today because the local mean time (LMT) was used back them (based on the longitude). This is per spec and WAI.
,
Jun 11 2018
Spoke with the engineer who submitted the changes and this is WAI.
,
Jun 20 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by kkaluri@chromium.org
, May 31 2018Labels: Needs-Feedback OS-Linux