New issue
Advanced search Search tips

Issue 919274 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

javascript Date() returns UTC timezone after PC suspend/resume on Win10

Reported by c.carson...@gmail.com, Jan 5

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce the problem:
I can reproduce (on Win 10) the timezone of Date() reverting to UTC (instead of local time) after suspending/resuming PC while in an open tab.  Steps:

1) With no extensions enabled, start Chrome
2) In a new blank tab's URL bar, enter 'javascript:alert(new Date())'
3) Verify that the current date & time is displayed in the OS's local timezone as expected. 
   E.g., 'Wed Nov 14 2018 16:43:03 GMT-0800 (GMT-08:00)'
4) Put the PC to sleep/suspend
5) Wake it up
6) In the same tab as in step #2, enter 'javascript:alert(new Date())'

What is the expected behavior?
The displayed date/time is in a local timezone,
  e.g. 'Wed Nov 14 2018 16:43:03 GMT-0800 (GMT-08:00)'

What went wrong?
The displayed date/time is now in UTC
   E.g., 'Thu Nov 15 2018 00:45:38 GMT+0000 (GMT)'

Did this work before? N/A 

Chrome version: 71.0.3578.98 (Official Build) (64-bit) (cohort: Stable)  Channel: stable
OS Version: 10.0
Flash Version: 32.0.0.101

some interesting additional observations:

7) In the same tab as #2 & #6, enter the URL of some website, and load it; e.g., https://www.google.com
8) after the page loads, enter 'javascript:alert(new Date())' again

RESULT: The displayed date & time is now back to the correct local timezone.

Alternately, after step #6, open a new blank tab, enter 'javascript:alert(new Date())'.  The result is the correct local timezone.

Throughout all of this, the system clock in the tray has never visibly indicated a timezone switch happening.

At some point many months ago, I originally noticed that some of the websites I visited were occasionally displaying local time incorrectly, and other odd behaviors.  In October, under 70.0.3538.102, I was able to correlate these symptoms with this buggy Date() behavior (i.e., the apps only misbehaved after a suspend/resume).  I added all the above information to  Issue 896759  , but that Issue ended up being merged into a Win-7-only issue, which was fixed in M71 and released. 

Google Chrome	71.0.3578.98 (Official Build) (64-bit) (cohort: Stable)
Revision	15234034d19b85dcd9a03b164ae89d04145d8368-refs/branch-heads/3578@{#897}
OS	Windows
JavaScript	V8 7.1.302.31
Flash	32.0.0.101 

System information:

OS Name	Microsoft Windows 10 Enterprise
Version	10.0.14393 Build 14393

(Note: I originally commented on this in
 
Labels: Needs-Triage-M71
Cc: viswa.karala@chromium.org
Components: Blink>JavaScript>Internationalization
Labels: Triaged-ET Needs-Feedback
Thanks for filing the issue!

As per comment# 0, issue seems to be similar to Issue:  913298 , which is Fixed in M-71, 72 & 73 milestones.

@Reporter: Could you please try to test this issue by creating new person and let us know if the issue still persists.
With reference to Issue: 913278, CC'ing Jungshik Shin(jshin@chromium.org) for providing further inputs on this issue.

Thanks!
Cc: js...@chromium.org
After creating a new person and in a browser window running under that person, I could still reproduce the issue following steps 2-6 while in a browser window.

I also shut down the browser process completely, restarted, switched to the new person created above, and could still reproduce the problem.


 
Project Member

Comment 5 by sheriffbot@chromium.org, Jan 7

Labels: -Needs-Feedback
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
While searching for potential duplicates:

Issue 830020 is similar, in that the incorrectly-reported timezone is specific to particular tabs (though he doesn't mention whether suspend/resume has anything to do with it)

There was another issue I found where someone commented that they were seeing the same behavior after a suspend/resume on a Mac.  As I recall, there was no followup to that comment.  But I can no longer find that issue.

Comment 7 Deleted

Comment 8 Deleted

This has been an issue for us, clients in EST are seeing 5 hours added to the time they enter or retrieve. I have been trying to find a solution for this issue. 

I am on Chrome version - 71.0.3578.80. 
This is not an issue on my co-worker's computer at version 65.

Comment 10 by hablich@chromium.org, Today (21 hours ago)

Owner: js...@chromium.org
Status: Assigned (was: Unconfirmed)

Sign in to add a comment