Unable to reproduce the issue on reported version 61.0.3163.91 and on latest canary 63.0.3220.0 on Mac 10.12.6, Windows and Ubuntu 14.04 with the mentioned steps below
1.Executed Intl.DateTimeFormat().resolvedOptions().timeZone in console of developer tools.
2. Returned ""Asia/Calcutta"". Attaching screenshot for reference.

Issue seems to be timezone specific.

Deleted: 766916.png 166 KB

	766916.png 166 KB View Download

@roy.mellon: Could you please re-try the scenario by creating a new profile without any extensions or apps. 

Please follow below steps to create a New profile
(i) Launch chrome>>Press Alt+E>>Settings)
(ii)Under the section headed People, Click on link Manage other people>>Add person 

If the issue still persist please provide your observation that would help us in further triaging of the issue 

I have seen both internal and external reports of the timezone being incorrectly detected as CDT (America/Chicago):

https://www.reddit.com/r/chromeos/comments/71u3c6/the_time_keeps_resetting_itself_to_chicago_time/

We are getting multiple reports of this problem on CBC.

https://productforums.google.com/forum/#!topic/chromebook-central/BqINRDSXa1w;context-place=forum/chromebook-central

CBC TC

I do it in Incognito Mode, without any extensions or apps.

Always the same.

Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

roy.mellon@ Thanks for the update..

Re-tested the issue again and unable to reproduce the issue on Windows 7, Mac OS 10.12.6 and Ubuntu 14.04 using the latest Canary 63.0.3223.0 and latest Stable 61.0.3163.100 with the below steps.

1. Launched Chrome and opened Devtools.
2. Under Console executed `Intl.DateTimeFormat().resolvedOptions().timeZone` and system is returning "Asia/Calcutta".

This result is returning based on the System settings. Attached is the screen shot for reference.

Can you please check your Timezone settings on your machine  and retry the issue. Please update the thread if there is any issue.

Thanks..

Deleted: 766916.png 111 KB

	766916.png 111 KB View Download

Same issue in Los Angeles, 2h west of Chicago. 

Google Chrome	60.0.3112.114 (Official Build) (64-bit)
Revision	0
Platform	9592.96.0 (Official Build) stable-channel reks
Firmware Version	Google_Reks.7287.133.81
Customization ID	LENOVO-REKS1

Screenshot attached.

Deleted: Screenshot 2017-09-25 at 9.28.03 AM.png 442 KB

	Screenshot 2017-09-25 at 9.28.03 AM.png 442 KB View Download

To add to Comment 9: on the Macbook pro I'm typing on now, which is on the same network as the Lenovo N22 chromebook, Intl.DateTimeFormat().resolvedOptions().timeZone returns "America/Los_Angeles". 

Google Chrome	60.0.3112.113 (Official Build) (64-bit)
Revision	95c454326a7a3153e984e50a4719924968490717-refs/branch-heads/3112@{#744}
OS	Mac OS X
JavaScript	V8 6.0.286.56

I'm using macos Sierra 10.12.5;

Locale setting is in China.

Using terminal `sudo systemsetup -gettimezone` returns 'Time Zone: Asia/Shanghai';

And retry Under Chrome V61 Console executed `Intl.DateTimeFormat().resolvedOptions().timeZone` and system is returning "America/Chicago".

And I'm sure that it return 'Asia/Shanghai' when I use Chrome version 58 in same computer an profile. 

Deleted: Snip20170927_208.png 47.8 KB

	Snip20170927_208.png 47.8 KB View Download

Deleted: Snip20170927_205.png 12.2 KB

	Snip20170927_205.png 12.2 KB View Download

Deleted: Snip20170927_206.png 23.5 KB

	Snip20170927_206.png 23.5 KB View Download

Deleted: Snip20170927_207.png 155 KB

	Snip20170927_207.png 155 KB View Download

Thank you for providing more feedback. Adding requester "susanjuniab@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi, we in Germany also have this problem:

> new Date
> Fri Sep 29 2017 09:32:35 GMT+0200 (CEST)
> (new Intl.DateTimeFormat()).resolvedOptions().timeZone
> "CET"

Version 61.0.3163.79 (Official Build) (64-bit)  running on Mac Os

Same here.

Version 61.0.3163.100 (Official Build) (64-bit) on OSX 10.12.6

> new Date()
Fri Sep 29 2017 09:48:28 GMT+0200 (CEST)
> (new Intl.DateTimeFormat()).resolvedOptions()
{"locale":"en-GB", "numberingSystem":"latn", "calendar":"gregory", "timeZone":"CET", "year":"numeric", "month":"2-digit", "day":"2-digit"}

Same system + same command on firefox returns:
> (new Intl.DateTimeFormat()).resolvedOptions()
{"locale":"en-DE", "calendar":"gregory", "numberingSystem":"latn", "timeZone":"Europe/Berlin", "day":"2-digit", "month":"2-digit", "year":"numeric"}

Seems like the locale is also be affected; it is reported as en-GB, but my region is definitely set to germany, as correctly reported on firefox.

The latest version of macOS has an issue. Newer versions of Ubuntu, RedHat and SuSe Linux also has an issue with timezone detection.  The way timezone datafile is stored has changed on those OS and ICU (used by v8) does not look for the new location. There's an upstream fix I'm going to apply, soon. 

I don't know about Windows. If this issue is also reproduced on Windows, this issue may not be the same as what I have in mind. 

I'll look into that. 

Ok. No actual user report on Windows, right? 

Then, this must be what I have in mind. Chrome OS should be fine, too. 

I will dupe it to  bug 754053  once I'm 100% sure that it's not affecting Windows. 

This is not a regression but the OS has changed (Chrome has not changed to deal with an OS change).  

#18 -
#1 suggests that it does affect those platforms, maybe from external/Google-internal reports. Can you synchronize with the author of the comment?

#19 - this is a regression for the user/developer, it does not matter if it is not a Chromium code regression...
(Not a regression lowers the priority)

Re: comment 1, 
 patricialor@ : why did you add OS=Windows and OS=Chrome? Have you heard about this issue on those platforms? 

Hmm...  roy.mellon@gmail.com,  your OS is macOS 10.12.5 (not macOS 10.13) ? In a terminal, can you run the following command and post the output ? 

ls -l /etc/localtime 



Per comment 9, adding back Chrome OS.  This may be a separate bug from  bug 754053 . 

I misread comment 9 and comment 10. 

In the screenshot attached to comment 9, Chrome OS misdetected the timezone to be America/Chicago (for a machine in America/Los_Angeles) and v8 just does the right thing given the OS timezone (which is America/Chicago). 

Dropping OS=Chrome again. 

 anwaya@gmail.com - Please, file a separate bug against Chrome OS and add a comment to this bug pointing to that new bug. Thanks !

This bug is about v8's Intl API returning timeZone 'America/Chicago' when the OS timezone is NOT America/Chicago. 

OTOH, your issue is that Chrome OS somehow misdetects the current timezone and set it incorrectly to America/Chicago. 

comment 4 and comment 5: They're also Chrome OS system timezone mis-detection issue.  (I have observed something interesting on my Chromebook). Once a separate bug on Chrome OS timezone detection is filed, I'll add my observation there. 

Adding Needs-Feedback to hear back from roy.mellon@gmail.com about my question in comment 22. 

Added 771847. However, I suspect that the root cause will be the same, that the ChromeOS code and the Chrome code for detecting location for timezone are the same.

Thank you for filing bug 771847. I put a comment there. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/deps/icu.git/+/21d33b1a09a77f033478ea4ffffb61e6970f83bd

commit 21d33b1a09a77f033478ea4ffffb61e6970f83bd
Author: Jungshik Shin <jshin@chromium.org>
Date: Wed Oct 11 18:45:03 2017

Fix timezone detection on macOS 10.13/newer Linux distros

The location of zoneinfo directory has changed on macOS 10.13,
Ubuntu 16, RHEL 7 and SuSe Linux 12. It results in the misdetection
of the OS timezone by ICU. Cherry-picking the CLs for the following
upstream bug fixes it.

https://ssl.icu-project.org/trac/ticket/12770

Bug:754053, 766916 
Test: In Javascript console, the following should give the correct
   timezone.
    (new Intl.DateTimeFormat()).resolvedOptions().timeZone

Change-Id: I711f4b27e73dc6855951055a601e80f711d34423
Reviewed-on: https://chromium-review.googlesource.com/710496
Reviewed-by: Mark Mentovai <mark@chromium.org>

[modify] https://crrev.com/21d33b1a09a77f033478ea4ffffb61e6970f83bd/README.chromium
[add] https://crrev.com/21d33b1a09a77f033478ea4ffffb61e6970f83bd/patches/timezone_detection.patch
[modify] https://crrev.com/21d33b1a09a77f033478ea4ffffb61e6970f83bd/source/common/putil.cpp

comment 14 and comment 15: getting 'CET' (from Intl.DateTimeFormat().resolvedOptions().timeZone )  on macOS instead of 'Europe/Berlin'. 

I'm pretty sure that it's macOS 10.13.  In that case, a fix recorded in comment 28 should take care of it. 

 sieber@boerse-go.de,  mail@mkleinhans.de : can you confirm that you have macOS 10.13 instead of 10.12 ?  


The original issue as reported by roy.mellon@gmail.com on macOS 10.12 is still outstanding. It may have the same root cause as bug 771847. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1b4f3c6bdfaf9fd610d2dabf11a686fd1df56951

commit 1b4f3c6bdfaf9fd610d2dabf11a686fd1df56951
Author: Jungshik Shin <jshin@chromium.org>
Date: Thu Oct 12 01:18:14 2017

Roll ICU to 21d33b1

This has one change to fix the OS timezone detection on macOS 10.13
and newer Linux distros such as Ubuntu 16, RHEL 7, SuSe 12 or newer.

 https://chromium.googlesource.com/chromium/deps/icu/+log/7f873c45..21d33b1a

    (new Intl.DateTimeFormat()).resolvedOptions().timeZone
TBR=mark@chromium.org

Bug:  754053 , 766916 
Test: In Javascript console, the following should give the correct timezone.
Change-Id: I9553905fb20f0bf0b99442b38b2e67082c6fc64d
Reviewed-on: https://chromium-review.googlesource.com/713959
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508199}
[modify] https://crrev.com/1b4f3c6bdfaf9fd610d2dabf11a686fd1df56951/DEPS

No, can not confirm. As mentioned in my original comment I have OSX 10.12.6

>  No, can not confirm. As mentioned in my original comment I have OSX 10.12.6

Thanks. Your issue in comment 15 is likely to have the same cause as  bug 774376  . 

As for en-DE vs en-GB, it's bug 99526 . 

roy.mellon@,  mail@mkleinhans.de  and others who observed this issue on macOS :

can you try a canary build ( 64.x) and see if this issue is fixed? 

I did that on macOS 10.12 and 10.13 (see 754053 ). Additional confirmation would be nice. 

> can you try a canary build ( 64.x) and see if this issue is fixed? 

You can install a Canary build side-by-side with your regular Chrome (stable, beta or dev). See https://www.chromium.org/getting-involved/dev-channel

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/15e55ed197f16bcb3e22467bdb0e9b389221e46b

commit 15e55ed197f16bcb3e22467bdb0e9b389221e46b
Author: Jungshik Shin <jungshik@google.com>
Date: Mon Oct 16 18:19:42 2017

from comment 15: 

> new Date()
Fri Sep 29 2017 09:48:28 GMT+0200 (CEST)
> (new Intl.DateTimeFormat()).resolvedOptions()
{"locale":"en-GB", "numberingSystem":"latn", "calendar":"gregory", "timeZone":"CET", "year":"numeric", "month":"2-digit", "day":"2-digit"}


This is a typical symptom of  bug 773532  (timeZOne is set to 'CET' in Intl.DateTimeFormat() instead of 'Europe/Berlin' (or other Central European timezone IDs). 

I can reproduce it in 61.0.3163.100 on macOS 10.12. With the latest trunk 64.0.4xxx..., 
the issue is fixed. 62.x and 63.x will also have a fix. 

Can you try this out in Chrome 61.0.3xxx ?  

1. Go to http://jungshik.github.io/cr/bugs/520783.html
2. Quit Chrome
3. Start Chrome
4. Go to http://jungshik.github.io/cr/bugs/520783.html
5. Create a new tab
6. Go to  http://jungshik.github.io/cr/bugs/520783.html

What's the output in steps 1, 4 and 6?  Thank you

With Asia/Shanghai in the OS timezone, I got this from the test page in comment 37:

toString: Tue Oct 17 2017 05:58:54 GMT+0800 (CST)
getTimezoneOffset: -480
valueOf/1000/3600: 418941.98178055556
Intl datetime with local tz: Oct 17, 2017, 5:58 AM Central Standard Time
Intl datetime with UTC: Oct 16, 2017, 9:58 PM Coordinated Universal Time
Intl datetime with tz = Honolulu: Oct 16, 2017, 11:58 AM Hawaii-Aleutian Standard Time
Intl datetime with tz = Calcutta : Oct 17, 2017, 3:28 AM India Standard Time
Intl.DateTimeFormat("en-US").resolvedOptions().timeZone: America/Chicago

And, now I know what's going on. It's yet another symptom of  bug 773532 . 

When /etc/localtime cannot be accessed due to sandboxing ( bug 773532  blocks the access to /etc/localtime), ICU (used for Intl.DateTimeFormat()) resorts to a less accurate method of the timezone detection. That method tries to find out the timezone from an ambiguous timezone abbreviation (CST can stand for Chinese Standard Time or US Central Standard Time among other things). So, Asia/Shanghai (=> Chinese Standard Time => CST) is treated as CST => America/Chicago. 

 bug 773532  was fixed in the trunk (canary : 64.x..). Chrome 62.x (that will turn stable tomorrow) and 63.x (dev channel and will soon beta) got the fix. So, the next release of 62.x and 63.x will NOT have this problem any more. 

The same thing happens on newer Linux distros (Ubutun 16.x or newer, RHEL 7, SuSe 12) for a different reason. That's due to  bug 754053 , but the result is the same. Asia/Shanghai would be mistaken for America/Chicago and CEST (Central European Summer Time) wouldn't be recognized and mistakend to be CET (Centreal European Time). 

The worst case is macOS 10.13. It suffers from both  bug 754053  and  bug 773532 . 
And, on macOS 10.13,  bug 773532  is not completely fixed for Date.toString() while it's fixed for Date.toLocaleString() and Intl.DateTimeFormat.  

Anyway, we can declare this bug to be fixed. 

The only remaining issue that have been talked about in this bug is bug 771847 on CrOS. 

 Issue 774376  has been merged into this issue.