Win 7 enterprise sp1, Canary v 72.0.3584.0 displays GMT time in gmail, yahoo mail  even when I try to change settings.  Production chrome and firefox display correct time.  Also located in Chicago.  

Second maybe related issue when I try to update canary from the "about" window, Canary shuts down and will not start again.  Had to uninstall/reinstall and same result.

I am experiencing this as well.

My Windows system clock is set to Pacific Daylight Time (Configured as -08:00 with daylight time corrections, so effectively -07:00).  But new Date() is returning the current date/time with an -08:00 offset, instead of the local -07:00.  E.g., if the local time is 17:05 PDT, Date() returns 16:05-08:00 instead of 17:05-07:00.

This is in Version 70.0.3538.67 (Official Build) (64-bit) running on Windows 10 Enterprise 10.0.14393 Build 14393 , but it was also ocurring in Version 69.0.3497.100 (Official Build) (64-bit).  I do not know if it was happening in previous versions, or if it happens always.  I just noticed occasionally that some of the websites I use will displaying local times 1-hour off (e.g. a scheduling website is displaying "current" appointments 1 hour earlier than they are actually scheduled).  I just thought now to test what timezone the browser thinks it is in, and got this result with Date().

I compared this to a colleague running Chrome on Windows, and his Date() returns -07:00.  Our Windows system clocks are configured the same way with respect to the local timezone and daylight savings correction.

After I made my previous comment, I shut down (hibernated) my laptop running Chrome, but left the Chrome process running.  This morning when I powered on & restored my laptop, at 08:53 AM local time (-07:00) I checked what Date() was returning, and now it is GMT-00:00:  (i.e., neither -07:00 nor -08:00)

    > new Date()
    Tue Oct 23 2018 15:53:40 GMT+0000 (GMT)

However, the example scheduling website I mentioned before was _not_ showing the current hour as 15:00 local time, but rather 07:00 local (instead of 08:00 as I expected).  So this symptom may be completely unrelated to the unexpected Date() timezone offset.

Tried testing the issue on reported chrome version #71.0.3578.10 and latest canary #72.0.3590.0 using Windows 10 by following below steps.

Steps:
=====
1.Launched chrome and changed the time zone to "UTC -5:00 Eastren Time (US & Canada)" with daylight saving time on.
5.Navigated to Devtools-Console.
3.Created an object  "new Date()" in console.
4.Observed that it displays the exact time which matches the system time.

Attached screencast for reference.
@reporter: Could you please check the attached screencast and let us know if anything is missed here. Request you to retry the issue by creating a new person without any apps and extensions installed, reset all flags to default on latest canary and let us know if the issue still exists.
Thanks.!

Deleted: 896759.mp4 2.2 MB

	896759.mp4 2.2 MB View Download

In response to Oct 25 commment with the screencast: My Chrome build shows a different version than yours, and my Windows machine is in a different timezone than yours (PST: -08:00).

Google Chrome	70.0.3538.77 (Official Build) (64-bit) (cohort: Stable)
Revision	0f6ce0b0cd63a12cb4eccea3637b1bc9a29148d9-refs/branch-heads/3538@{#1039}
OS	Windows
JavaScript	V8 7.0.276.32

I am currently experiencing the problem, but again, in a browser session that is multiple days old, and all my extensions active (since I don't yet know what triggers it - I just notice at some point of normal browser usage that it has started happening)

My Windows system clock shows the correct local time (9:35AM UTC-08:00), but 'new Date()' returns UTC+0000

  new Date()
  Tue Nov 13 2018 17:27:40 GMT+0000 (GMT)

I have noticed that the problem is specific to a tab - In tab A, Date() shows as +00:00.  I created a new Tab B, and in it, it is showing the correct local timezone:

Tab A:
  new Date()
  Tue Nov 13 2018 17:27:40 GMT+0000 (GMT)
Tab B:
  new Date()
  Tue Nov 13 2018 09:27:52 GMT-0800 (GMT-08:00)

I originally opened Tab A yesterday, and while I was using it yesterday, the side-effects of a bad timezone in were not occurring in the web pages it displayed.  But this morning, it was obvious that pages loaded into the tab were using the wrong timezone (it's my aforementioned scheduling webpages that display appointments in the local timezone). but Tab B I just created today.  In fact, I have a number of tabs still open from yesterday, and they all are showing a TZ of 0, but all new tabs created today have a TZ of -08:00.

I will attempt to disable extensions & use the browser to see if the problem recurs.  If it is possible for an extension to be changing the browser's timezone, can this be logged somehow to catch the culprit?

Deleted: datetimesettings.PNG 41.5 KB

	datetimesettings.PNG 41.5 KB View Download

I haven't yet tried reproducing this in a clean browser, but I did just experience that all of my formerly "good" tabs have now switched to the wrong timezone (UTC, not PST).  The only specific thing I can think that I did, was to undock my laptop from its docking station with a wired network connection, which caused it to switch to use the WiFi network.  Then I came back to my desk, docked it again, and that's when I noticed that the timezone had changed.  I don't recall whether the laptop suspended/resumed when I docked or undocked the laptop.

OK, I've narrowed down the minimal repro steps in my environment:

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())'

RESULT: The displayed date & time is now in the wrong timezone
   E.g., 'Thu Nov 15 2018 00:45:38 GMT+0000 (GMT)'

Continuing, there are 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.

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

INFO:

From Chrome about://version
Google Chrome	70.0.3538.102 (Official Build) (64-bit) (cohort: Stable)
Revision	4bbeebac88fdc09c97265e47c205868bbd190497-refs/branch-heads/3538@{#1077}
OS	Windows
JavaScript	V8 7.0.276.38
Flash	31.0.0.148 C:\Users\ccthomas\AppData\Local\Google\Chrome\User Data\PepperFlash\31.0.0.148\pepflashplayer.dll
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36
Command Line	"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Executable Path	C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

Selected info from Windows System Information app:

OS Name	Microsoft Windows 10 Enterprise
Version	10.0.14393 Build 14393
System Manufacturer	Dell Inc.
System Model	Latitude E7450
BIOS Version/Date	Dell Inc. A09, 11/18/2015
SMBIOS Version	2.8
Embedded Controller Version	255.255
BIOS Mode	Legacy

"Messages for web" (https://messages.android.com/) exhibits this issue after updating to Chrome 71 Stable version. Daylight Savings is completely ignored. For example, an SMS sent at 8:51 AM from my phone shows that it was sent at 7:51 AM on the browser web app.

We have the same issue here, Windows 7 + Chrome 71.

In our internal ERP "2019-05-02 00:00:00+0200" is shown as 2019/05/01, it is extremely blocking for our business since nobody can register new contracts from now on...

Using Jira software, we now have a pop-in telling us that the time zone is wrongly configured and that we should change it in our profile.

Is it linked to the new Intl.RelativeTimeFormat API?

Just found this Reddit thread about the same issue : https://www.reddit.com/r/chrome/comments/a3l8wf/help_chromes_tim895769ezone_isnt_the_same_as_my_actual/

I can confirm that "Intl.DateTimeFormat().resolvedOptions().timeZone" returns "undefined" on Windows 7 + Chrome 71 (and "Europe/Paris" on other combinations, e.g Linux + Chrome 71, Windows + Firefox, etc.)

 Issue 912631  has been merged into this issue.

Simple repro case on three computers using "Europe/Paris" timezone (next DST on 31/03/2019).

Windows 7 / Chrome 71 (timeZone KO => DST from 31/03/2019 KO):

> Intl.DateTimeFormat().resolvedOptions().timeZone
< undefined
> new Date('2019-03-30T00:00:00.000+0100')
< Sat Mar 30 2019 00:00:00 GMT+0100 (UTC+01:00)
> new Date('2019-04-01T00:00:00.000+0200')
< Sun Mar 31 2019 23:00:00 GMT+0100 (UTC+01:00)

Windows 10 / Chrome 71 (OK):

> Intl.DateTimeFormat().resolvedOptions().timeZone
< "Europe/Paris"
> new Date('2019-03-30T00:00:00.000+0100')
< Sat Mar 30 2019 00:00:00 GMT+0100 (heure normale d’Europe centrale)
> new Date('2019-04-01T00:00:00.000+0200')
< Mon Apr 01 2019 00:00:00 GMT+0200 (heure d’été d’Europe centrale)

Linux / Chrome 70 (OK):

> Intl.DateTimeFormat().resolvedOptions().timeZone
< "Europe/Paris"
> new Date('2019-03-30T00:00:00.000+0100')
< Sat Mar 30 2019 00:00:00 GMT+0100 (heure normale d’Europe centrale)
> new Date('2019-04-01T00:00:00.000+0200')
< Mon Apr 01 2019 00:00:00 GMT+0200 (heure d’été d’Europe centrale)

Linux / Chrome 71 (OK):

> Intl.DateTimeFormat().resolvedOptions().timeZone
< "Europe/Paris"
> new Date('2019-03-30T00:00:00.000+0100')
< Sat Mar 30 2019 00:00:00 GMT+0100 (heure normale d’Europe centrale)
> new Date('2019-04-01T00:00:00.000+0200')
< Mon Apr 01 2019 00:00:00 GMT+0200 (heure d’été d’Europe centrale)

Same issue as https://bugs.chromium.org/p/chromium/issues/detail?id=913298

Hey all, thanks for reporting.

I'm going to mark this as a duplicate against  bug 913298  since that one has been repro'd and is being triaged.

 bug 913298  has been confirmed to only affect Windows 7, and not Windows 10.  But I am definitely able to reproduce problems on Windows 10, so I would like to propose that this be reopened as a separate bug.

Also note that all other reporters report symptoms of daylight savings being wrong.  But in my (latest) reproductions, the local time zone reverts to UTC.  So in that aspect it is different than the other bug reports.

Since this report has a lot of different symptoms from different reporters conflated together, and has already been merged with the  Issue 913298 , I've gone ahead and opened new Issue 919274 to address the very specific Win10-suspend-resume symptoms still present in M71.  Thanks.