Closed
Bug 1501721
Opened 6 years ago
Closed 5 years ago
Websites report local time as though time zone is UTC, actually Europe/London
Categories
(Core :: JavaScript Engine, defect, P5)
Tracking
()
RESOLVED
FIXED
mozilla65
Tracking | Status | |
---|---|---|
firefox65 | --- | fixed |
People
(Reporter: matthew.bugzilla, Assigned: anba)
References
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: Since upgrading to Firefox 63 today, default times on an internal website I use are an hour behind my system time. http://browserspy.dk/date.php also shows the problem. Actual results: It reports time and date as "Wed Oct 24 2018 16:14:13 GMT+0000 (GMT)" but my system time is 17:14 and my time zone is London. Chrome shows "Wed Oct 24 2018 17:14:13 GMT+0100 (British Summer Time)". Expected results: The website should get the correct time zone information from Windows and use that to calculate the system time correctly, as Chrome does, and as Firefox 62 did.
Comment 1•6 years ago
|
||
My local time is correctly shonwn on browserspy.dk with "Time and date Wed Oct 24 2018 22:27:33 GMT+0200"
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Reporter | ||
Comment 2•6 years ago
|
||
Interesting, I've now tried it on Windows 7 and Windows 10 and they both work fine. My machine at work (which shows the problem) runs Windows Server 2008 R2.
Assignee | ||
Comment 3•6 years ago
|
||
Firefox 63 switched to ICU for more date/time related operations, which should actually result in the same behaviour as Chrome, given that Chrome is also using ICU for most date/time operations. Hmm, I wonder if the "TZ" environment variable is set on the Windows Server 2008 system, because for backwards-compatibility reasons we support some "TZ" environment variable settings on Windows.
Reporter | ||
Comment 4•6 years ago
|
||
No, there is no TZ environment variable on this system.
Reporter | ||
Comment 5•6 years ago
|
||
Let me know if there is any other information I can provide or tests I can run to help with this. Note that daylight saving time in the UK ends this weekend, so today and tomorrow will probably be the last chance to reproduce this until the end of March next year.
Assignee | ||
Comment 6•6 years ago
|
||
I've just installed the Win 2008 Server (x64) evaluation version (en-US download, but installed with en-GB settings; downloaded Firefox 63 en-GB), and I'm not able to reproduce the issue. Now I'm downloading the Windows updates, currently at 20 of 158.
Reporter | ||
Comment 7•6 years ago
|
||
Note that 2008 is not the same as 2008 R2.
Assignee | ||
Comment 8•6 years ago
|
||
I've installed "Windows Server 2008 R2 Standard" (currently with Service Pack 1).
Reporter | ||
Comment 9•6 years ago
|
||
Pasting "Intl.DateTimeFormat().resolvedOptions().timeZone" into the console returns "UTC". The same test in Chrome returns "Europe/London".
Assignee | ||
Comment 10•6 years ago
|
||
Unfortunately I'm still not able to reproduce the issue when using the following configuration: - Windows Server 2008 R2 Standard (SP1), latest updates installed - OS language set to: en-GB - OS time zone set to: (UTC+00:00) Dublin, Edinburgh, Lisbon, London - Also verified that HKLM/SYSTEM/CurrentControlSet/Control/TimeZoneInformation/TimeZoneKeyName is set to "GMT Standard Time" - Firefox: release 63, en-GB (no add-ons installed, no settings modified) The aforementioned ICU library reads the time zone settings directly from the Windows registry, maybe Firefox is not allowed to read the relevant registry key? I'm also a bit confused why the time zone name is only "(GMT)", because normally it should be "(Greenwich Mean Time)" for the GMT time zone resp. "(Coordinated Universal Time)" for the UTC time zone. --- Hmm, so I just found out when I manually modify HKLM/SYSTEM/CurrentControlSet/Control/TimeZoneInformation/TimeZoneKeyName to some other value (for example by adding an extra "X", so it's now "GMT Standard TimeX"), I can reproduce the issue. Well, except that it also affects the output for Chrome.
Reporter | ||
Comment 11•6 years ago
|
||
Anything else I can do to help? Rebooting my system has made no difference.
Assignee | ||
Comment 12•6 years ago
|
||
(In reply to Matthew Kogan from comment #11) > Anything else I can do to help? Rebooting my system has made no difference. Are any of your system settings fundamentally different than the ones in comment #10? There are similar Chromium bugs for Windows Server 2008 R2 for RDP sessions [1,2]. Maybe this a related issue? (Except Chrome (releases 67/69-70) should also report the wrong time zone in your case...) There's also [3], but that one is Chrome 71 and also affects Win7/Win10, so I'm not sure it's related. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=854387 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=891206 [3] https://bugs.chromium.org/p/chromium/issues/detail?id=896759
Reporter | ||
Comment 13•6 years ago
|
||
My system settings are the same as those in comment #10. I am using the system via RDP. As I expected (and as I mentioned in comment #5) the time is no longer incorrect because daylight saving time in the UK ended yesterday. http://browserspy.dk/date.php now reports "Mon Oct 29 2018 11:34:53 GMT+0000 (GMT)" in Firefox and "Mon Oct 29 2018 11:35:39 GMT+0000 (Greenwich Mean Time)" in Chrome.
Assignee | ||
Comment 14•6 years ago
|
||
Great, thanks for the info! I guess the important bit to reproduce the bug is using RDP to access the system, similar to the linked Chromium issues from above. So, as soon as we update to ICU 63 (bug 1499026), we'll get this fix [1], which should result in resolving the correct time zone even when accessing a system over RDP. [1] https://unicode-org.atlassian.net/browse/ICU-13842
Depends on: 1499026
Reporter | ||
Comment 15•6 years ago
|
||
Thank you. Bug 1499026 is marked as wontfix for Firefox 64. Am I correct in saying that this is currently expected to be fixed in Firefox 65, which is due for release on 29th January 2019, then?
Assignee | ||
Comment 16•6 years ago
|
||
Yes, Firefox 65 will be the first release which contains a fix for this issue, because right now I don't expect bug 1499026 will get backported to the Beta branch for Firefox 64.
Updated•5 years ago
|
Priority: -- → P5
Reporter | ||
Comment 17•5 years ago
|
||
Firefox 65 has been released. Did anyone else ever manage to reproduce this issue? I want to know whether it has been fixed, but I can't test it because the UK is not on daylight saving time.
Reporter | ||
Comment 18•5 years ago
|
||
Actually I have managed to test it now, using a new Windows Server 2008 R2 VM, set to UTC, and a date when daylight saving would apply, then enabling time zone redirection for RDP, and remoting onto it from a machine set to the UK time zone. All seems to work fine in Firefox 65 (and not fine in Firefox 64).
Comment 19•5 years ago
|
||
Thanks for the confirmation!
Assignee: nobody → andrebargull
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in
before you can comment on or make changes to this bug.
Description
•