We are also seeing this bug across our user-base at https://superhuman.com/. Usually it manifests when people fly internationally, and then our website renders all timezones in UTC.

This has regressed since Chrome 59, as it seems to work fine there.

@superhuman.com this is exactly how we discover this bug.

Able to reproduce this issue on Mac 10.12.6 with Chrome reported version 61.0.3163.100 and latest beta 62.0.3202.52 but the same is not see on latest canary 63.0.3238.0 as per below steps:

1. Open chrome with new tab and load any website (www.google.com)
2. Change the system Time zone to Portland_United States,  Open developers tools and enter new Date() in console. See the result  (shown as per Portland time zone)
3. Now again change the system Time zone to Toronto_Canada. On the same tab, Open developers tools and enter new Date(). See the result (Does not show as per Canada time zone)
4. On the same window, open new tab and load any web page(www.facebook.com), enter new Date() (Shown as per Canada time zone)
5. Switch tab to first tab and Enter new Date() in console (Does not show as per Canada time Zone)

Note: Issue is not reproducible on Ubuntu 14.04 and Win 10 

Manual Bisect:
-------------
Good Build: 61.0.3119.0 - Revision - 476838
Bad Build: 61.0.3121.0 - Revision - 477034

Bisect Tool - Info:
---------------
You are probably looking for a change made after 477019 (known good), but no later than 477020 (first known bad).

CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/d801058048b2af3c21e32efe9137561ead01e5ed..a2e4f7f5c265cc867f21564d027afaf6a31550a9

Possible suspect:
 https://codereview.chromium.org/2919963003
Kerrnel@,Kindly take a look and please help us to reassign this issue to a right owner if not with respect to this change.

Thanks.!

From the sandbox logging:

default	11:37:21.483061 -0700	kernel	SandboxViolation: Google Chrome He(23838) deny(1) file-read-data /usr/share/zoneinfo/UTC
default	11:37:21.483117 -0700	kernel	SandboxViolation: Google Chrome He(23838) deny(1) file-read-data /usr/share/zoneinfo/posixrules
default	11:37:21.483134 -0700	kernel	SandboxViolation: Google Chrome He(23810) deny(1) file-read-data /usr/share/zoneinfo/UTC
default	11:37:21.483190 -0700	kernel	SandboxViolation: Google Chrome He(23810) deny(1) file-read-data /usr/share/zoneinfo/posixrules

Should be easy to fix.

This issue got fixed on chrome latest canary, hence providing reverse bisect information below.

Bisect Information:
-------------------
Good Build: 63.0.3212.0
Bad Build:  63.0.3213.0

You are probably looking for a change made after 501059 (known good), but no later than 501060 (first known bad).

CHANGELOG URL:
---------------  https://chromium.googlesource.com/chromium/src/+log/af92ddb997a848f65fa5d8d2c4a77b4ca809427b..0fc0c41c701aecd6c10a16927f4706beae7a50f8

From the above V8 changes suspecting the below change
https://chromium.googlesource.com/v8/v8/+/d9a25842d3aba82ead5e06c7fd7cb4896e6ad202

jshin@ Could you please take a look in to this issue.

Thanks!

brajkumar@: are you saying that this bug is fixed by https://chromium.googlesource.com/v8/v8/+/d9a25842d3aba82ead5e06c7fd7cb4896e6ad202 ( enabling ICU timezone data) ?   

That was reverted a couple of days ago because of   bug 771868  and other bugs. 
So merging that to M62 is not a good idea. 

This bug was observed in and reported against Chrome 61.x and 62.x (that does not have the above v8 CL - use ICU timezone data for Date.prototype.toString() ).   And the symptom is kinda the opposite of  bug 774376  . 


So, before v8 switched to use the ICU timezone data for Date.toString(), this bug was present.  
When v8 switched to use the ICU timezone data, this issue was resolved, but  bug 771868  popped up (the root cause for  bug 771868  is  bug 774376 ). 

The fix for  bug 774376  is easy, after which we can go back to using the ICU timezone data in v8.  Then both this bug and  bug 771868  would be fixed on Mac. 

Well, there's an issue: v8;s d9a25842 was reverted for multiple reasons. 1. performance loss ( bug 769706 ) 2.  bug 612010  on Linux/CrOS. 

 bug 612010  can be worked around if v8 is made to rely on the ICU timezone data only on Mac, but perf-loss ( bug 769706 ) is still an issue. 

I can/have to sort all these out and land again v8's ICU-timezone-enabling CL. However, it'll take time and I'm pulled in multiple directions today. :-)  
Moreover, we're talking about fixing this bug in M62.  

Even if I can sort out all these issues, merging all of fixes to M62 is not a good idea. 

A better alternative for M62 branch (and M63 branch) is to find out what happened with 
https://codereview.chromium.org/2919963003  (sandbox policy change), which was found by the bisecting in comment 4. 

IIRC, there's a sandbox hole for localtime*(), but it appears that that's not sufficient and that a sandbox hole for /usr/share/zoneinfo is also necessary. Well, I haven't taken a look at https://codereview.chromium.org/2919963003 to see what was changed. Anyway, changing the sandbox policy back to where it used to be for time/timezone related API/files on macOS should fix this issue. 

kerrnel@, would you take a look?  Thanks 

Well,  bug 754280  already deals with it.  Wait, it's for macOS 10.13 (nnd this bug was reported on macOS 10.12)  and a chance is already in M62. 

 kerrnel@,  why is reading /usr/share/zoneinfo/UTC denied?  I thought anything below /usr/share/zoneinfo is allowed according to the current sandbox rules. 

I'm seeing the sandbox errors and am currently doing a full m-62 build locally to debug. I will update everyone, thanks.

This is because some code reads the actual metadata of the /etc symlink and not the /private/etc target. I have a one line sandbox fix coming.

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

commit 950920975019ba6abcf23411924c29126582679a
Author: Greg Kerr <kerrnel@chromium.org>
Date: Fri Oct 13 19:41:07 2017

macOS Sandbox: Allow reading of the /etc symlink

Some code reads the metadata of the actual /etc symlink, so that path
needs to be allowed by the sandbox.

Bug:  773532 
Change-Id: I663b5e4f62705bbc42cd7a83578d63279ad8cb0c
Reviewed-on: https://chromium-review.googlesource.com/719407
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Greg Kerr <kerrnel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508781}
[modify] https://crrev.com/950920975019ba6abcf23411924c29126582679a/services/service_manager/sandbox/mac/renderer.sb

This bug requires manual review: We are only 3 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

Seems like a fairly small change. Can we test it out in Canary first and verify if it solves the issue? Since we're going to M62 stable next week, bar is high for merges and only accepting critical and safe merges. 

Yes, once we verify it in canary we should at least merge it to 63. I don't know how critical this functionality is so I'm not sure I can be the one to decide if it must go into m-62.

It causes us to receive about 1 email per day from confused customers. It might be exacerbated by the fact that people keep email clients open for a long time, but I imagine this is also affecting Gmail.

Sent via Superhuman ( https://sprh.mn/?vip=conrad@superhuman.com )

On Fri, Oct 13, 2017 at 3:11 PM, kerr… < monorail+v2.744916248@chromium.org > wrote:

Thanks for the info. The change is tiny and low risk, so if someone on the release team decides to take it for m-62, I'll make the merge happen. 

Thanks for response to this! We have very similar situation as superhuman.com. The reports are happing everyday. 

I'm pretty sure google calendar and other calendaring products are also affected. 

Your change meets the bar and is auto-approved for M63. Please go ahead and merge the CL to branch 3239 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

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

I'd argue that  this should be merged into M62 as well. Travellers across timezones would suffer from this issue. Restarting Chrome or opening a new tab is a work around, but still it's a regression and inconvenient to some users. 
Moreover, a change is very tiny. 

And, this may have fixed  bug 774376  as well (there are more than one timezone related changes landed recently, but this one is likely to have fixed  bug 774376 ). 

This issue also affects those who don't travel at all if they visit web pages using EcmaScript's Intl.DateTimeFormat API (AngularJS does use it). See  bug 754053  . ICU extracts the Olson timezone ID from the target path of /etc/localtime. So, that's another reason to merge the fix for this bug to M-62. 

My test at http://i18nl10n.com/chrome/tzchange.html 

64.0.3241.0 

1. macOS 10.12:  both Date.prototype.toString() and Date.prototype.toLocaleString() (or Intl.DateTimeFormat().format() ) work as expected. The timezone is correct after a timezone change in both an existing tab and a new tab. 

2. macOS 10.13:  Date.prototype.toLocaleString() / Intl.DateTimeFormat() works fine, but Date.prototype.toString() still has UTC after a timezone change in the existing tab. New tabs are fine. 


 kerrnel@ : how can I enable the sandbox logging ? I have macOS 10.13 installed on my personal MBA with rather small disk space and I don't have Chrome dev set-up there. 

1.Go to  http://jungshik.github.io/cr/bugs/520783.html
2. Change the OS timezone 
3. Click  'Recheck' button in an existing tab with the above page
4. Open a new tab and go to the above page

In step 3, the first line (Date.toString) and the 2nd line are broken on macOS 10.13 with CHrome 64.0.3241.0. It has UTC and offset=0. 

In step 4, all the output lines are correct. 

On macOS 10.12, the same Chrome canary works fine for all cases. 

Step 3 output on macOS 10.13 in an existing tab:

toString: Mon Oct 16 2017 05:24:28 GMT+0000 (UTC)   <=== wrong
getTimezoneOffset: 0    <=== wrong: should be -660 
valueOf/1000/3600: 418925.4079602778
Intl datetime with local tz: Oct 16, 2017, 4:24 PM Australian Eastern Daylight Time
Intl datetime with UTC: Oct 16, 2017, 5:24 AM Coordinated Universal Time
Intl datetime with tz = Honolulu: Oct 15, 2017, 7:24 PM Hawaii-Aleutian Standard Time
Intl datetime with tz = Calcutta : Oct 16, 2017, 10:54 AM India Standard Time
Intl.DateTimeFormat("en-US").resolvedOptions().timeZone: Australia/Sydney

Step 4 output on macOS 10.13 / 10.12 and step 3 output on macOS 10.12 : all correct

toString: Mon Oct 16 2017 16:23:29 GMT+1100 (AEDT)
getTimezoneOffset: -660
valueOf/1000/3600: 418925.3915313889
Intl datetime with local tz: Oct 16, 2017, 4:23 PM Australian Eastern Daylight Time
Intl datetime with UTC: Oct 16, 2017, 5:23 AM Coordinated Universal Time
Intl datetime with tz = Honolulu: Oct 15, 2017, 7:23 PM Hawaii-Aleutian Standard Time
Intl datetime with tz = Calcutta : Oct 16, 2017, 10:53 AM India Standard Time
Intl.DateTimeFormat("en-US").resolvedOptions().timeZone: Australia/Sydney
 

** Bulk Edit **

Please merge your change to M63 branch 3239 before 5:00 PM PT Monday (10/16) so we can take it in for next dev release. Thank you.

Enabling icu_timezone_data in v8 ( --js-flags="--icu_timezone_data" in Chrome command line) solves this issue for Date.toString and related API as expected, but it's currently disabled for a couple of reasons (1. perf regression ( bug 769706  ) 2. Linux/Chrome OS new tab issue -  bug 612010  ).  

ICU only needs to know the target path of /etc/localtime and the CL in comment 13 allows that.  OTOH, it appears that localtime*() need to read the actual contents of zoneinfo files. The current sb rules allow reading /usr/share/zoneinfo.default and its subpath.  Should (the metadata of) /var/db/timezone/zoneinfo and its subpath be opened up explicitly (even though /var/db/timezone/zoneinfo is a symlink to /usr/share/zoneinfo.default )? 

$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.13
BuildVersion:   17A405
$ ls -ld /etc
lrwxr-xr-x@ 1 root  wheel  11 Oct 15 16:07 /etc -> private/etc
$ ls -l /etc/localtime 
lrwxr-xr-x  1 root  wheel  44 Oct 16 16:35 /etc/localtime -> /var/db/timezone/zoneinfo/Australia/Brisbane
$ ls -ld /var
lrwxr-xr-x@ 1 root  wheel  11 Oct 15 16:08 /var -> private/var
$ ls -ld /var/db/timezone/zoneinfo
lrwxr-xr-x  1 root  wheel  27 Oct 15 16:07 /var/db/timezone/zoneinfo -> /usr/share/zoneinfo.default
$ ls -ld /usr/share/zoneinfo
lrwxr-xr-x  1 root  wheel  25 Oct 15 16:08 /usr/share/zoneinfo -> /var/db/timezone/zoneinfo

--no-sandbox command line flag makes step 3 in comment 26 work correctly on macOS 10.13. So, it's definitely a sandbox issue. 

I'll look at 10.l3 further, but to see sandbox denials pass --enable-sandbox-logging

Thanks kerrnel@ and jshin@ - can you confirm if #13 still needs to be merge in M62? Did we verify it over the weekend in canary?

re: comment 32:  With the current fix combined with the ICU fix for  bug 754053 , Intl.DateTimeFormat() and Date.toLocaleString() are completely fixed on macOS 10.13. 

So, I'd say that the current fix recorded here has to be merged first to M62. Then, we can wait for kerrnel@'s additional fix for macOS 10.13. 

What's still outstanding is Date.toString() and Date.getTimeZoneOffset() (sp?) on macOS 10.13 when the timezone is changed. 

What I wrote in comment 33 is based on my tests with two 64.x canary builds on macOS 10.12 and macOS 10.13. See comment 23, comment 24, comment 26 and comment 27. 

See also https://bugs.chromium.org/p/chromium/issues/detail?id=754053#c27 ( bug 754053  comment 27). 

Just as a heads up, the sandboxing changes are totally unrelated to the ICU changes, so this bug will be easier to follow if we just discuss the sandboxing issues here.

Approving merge to M62. Branch:3202

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

commit 057fbe9d0b353b4d445107d9ed063a7b76d17096
Author: Greg Kerr <kerrnel@chromium.org>
Date: Mon Oct 16 20:06:37 2017

[MERGE M62] macOS Sandbox: Allow reading of the /etc symlink

Some code reads the metadata of the actual /etc symlink, so that path
needs to be allowed by the sandbox.

Bug:  773532 
Change-Id: Ic19307d4ab3cf4c3cab15c822b9770a074cfcdd2
Reviewed-on: https://chromium-review.googlesource.com/721864
Reviewed-by: Greg Kerr <kerrnel@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#694}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/057fbe9d0b353b4d445107d9ed063a7b76d17096/content/renderer/renderer.sb

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

commit 6bc97ad7decfe8213ad9b89559749bde85762c68
Author: Greg Kerr <kerrnel@chromium.org>
Date: Mon Oct 16 20:14:20 2017

macOS Sandbox: Allow reading of the /etc symlink

Some code reads the metadata of the actual /etc symlink, so that path
needs to be allowed by the sandbox.

Bug:  773532 
Change-Id: I663b5e4f62705bbc42cd7a83578d63279ad8cb0c
Reviewed-on: https://chromium-review.googlesource.com/719407
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Greg Kerr <kerrnel@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#508781}(cherry picked from commit 950920975019ba6abcf23411924c29126582679a)
Reviewed-on: https://chromium-review.googlesource.com/721874
Cr-Commit-Position: refs/branch-heads/3239@{#15}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/6bc97ad7decfe8213ad9b89559749bde85762c68/services/service_manager/sandbox/mac/renderer.sb

?This is now in 62 and 63. I need to look at the 10.13 issues though.

Interesting I built top of tree and could not reproduce this, but it does reproduce in Canary 64.0.3241.0.

Thanks for merging to 62 and 63 branches. 

> Interesting I built top of tree and could not reproduce this, but it does reproduce in Canary 64.0.3241.0.

Just a guess... 
Any chance that sandbox does not kick in for your ToT build (for an unknown reason)? 

Until I tried '--no-sandbox' (comment 30), I was wondering if the timezone monitoring is not working as intended on macOS 10.13. Because --no-sandbox flag makes Date.toString() work properly on macOS 10.13, I didn't look further along that direction (timezone monitoring). 

Great suggestion. It doesn't disable the sandbox but the new V2 sandbox is now enabled on all developer builds, but not yet canary builds. :-)

Once I switched to the current sandbox I reproduced:
deny file-read-metadata /private/var/db/timezone/zoneinfo

I'll fix this, will we want to merge the 10.13 fixes to M-62? Is there time?

Can we consider this for our next M62 Respin? not planned yet, but probably next week. 

Verified this issue on Mac OS 10.12.6 using chrome latest M62-62.0.3202.62 and observed the timezone is correctly displayed when the system timezone changes as expected. Hence adding TE-Verified label.

Thanks!

Deleted: Screen Shot 2017-10-17 at 5.00.40 AM.png 135 KB

	Screen Shot 2017-10-17 at 5.00.40 AM.png 135 KB View Download

Thanks, kerrnel@ !! 
It seems that my hunch about /var/db/timezone/zoneinfo in comment 29 was kinda right. :-)

re comment 48: 

 brajkumar@: you need to try the procedure in comment 26 to verify both Date.toString() and Date.toLocaleString /Intl.DateTimeFormat.format work properly.  And, it has to be done on both macOS 10.12 and macOS 10.13. For macOS 10.13, you need to wait for kerrnel@ to submit an additional fix. 

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

commit 0af01a8d57b03fd2174bd0faa4986572dab89a39
Author: Greg Kerr <kerrnel@chromium.org>
Date: Tue Oct 17 18:34:34 2017

macOS Sandbox: Fix timezone information on 10.13.

This fixes the sandbox rules to access timezone information specifically
on 10.13.

Bug:  773532 
Change-Id: I32dc858a9607b10aa7db4df464a627d02d89b683
Reviewed-on: https://chromium-review.googlesource.com/722203
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Greg Kerr <kerrnel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509436}
[modify] https://crrev.com/0af01a8d57b03fd2174bd0faa4986572dab89a39/services/service_manager/sandbox/mac/renderer.sb

Tested this issue on Mac 10.12.6 & 10.13 using chrome#63.0.3239.9 as per C#4 & C#49 and observed timezone is displayed correctly when the system time zone is changed which is as intended behavior.Hence adding TE-Verified labels.

Please find the attached screencasts of both Mac 10.12.6 & mac 10.13.

Thanks..!

Deleted: 773532-Mac 10.12.mp4 4.4 MB

	773532-Mac 10.12.mp4 4.4 MB View Download

Deleted: 773532-Mac 10.13.mp4 2.7 MB

	773532-Mac 10.13.mp4 2.7 MB View Download

Verified this issue on Mac OS 10.13 using chrome latest canary M64-64.0.3243.0 by following steps mentioned in comment #26. Observed able to see the expected TimezoneOffset as expected in line 2. Attaching screenshot for reference.

Thanks!

Deleted: TimeZone 10.13 .png 469 KB

	TimeZone 10.13 .png 469 KB View Download

Requesting merge. should we pick this up for the next m-62 release?

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

Is there any work around in JS api that can help our users? Like can we some how force refresh Timezone for the active tab. 

The problem is that the sandbox blocks access to read the updated timezone, so I don't think there's a workaround aside from us shipping the fixes. 

I see. I don't quite fallow your release process:). When we can expect the fix hit people computers. 

Approving #50 for merge to M62. Branch:3202

Your change meets the bar and is auto-approved for M63. Please go ahead and merge the CL to branch 3239 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

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

Is there anything pending for M63? If not, please remove "Merge-Approved-63" label. Thank you.

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

commit 1e7395d50e1d9bde1ff36be8d496b3c332adcb24
Author: Greg Kerr <kerrnel@chromium.org>
Date: Thu Oct 19 17:44:01 2017

macOS Sandbox: Fix timezone information on 10.13.

This fixes the sandbox rules to access timezone information specifically
on 10.13.

Bug:  773532 
Change-Id: I32dc858a9607b10aa7db4df464a627d02d89b683
Reviewed-on: https://chromium-review.googlesource.com/722203
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Greg Kerr <kerrnel@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#509436}(cherry picked from commit 0af01a8d57b03fd2174bd0faa4986572dab89a39)
Reviewed-on: https://chromium-review.googlesource.com/728619
Reviewed-by: Greg Kerr <kerrnel@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#74}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/1e7395d50e1d9bde1ff36be8d496b3c332adcb24/services/service_manager/sandbox/mac/renderer.sb

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

commit a5c5b124d0824a541434024f9521f583d87028b8
Author: Greg Kerr <kerrnel@chromium.org>
Date: Thu Oct 19 21:57:41 2017

[MERGE M62] macOS Sandbox: Fix timezone information on 10.13.

This fixes the sandbox rules to access timezone information specifically
on 10.13.

Bug:  773532 
Change-Id: Id00cfd60c677daa65112a0bc66867aa14dfa6b09
Reviewed-on: https://chromium-review.googlesource.com/729142
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#719}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/a5c5b124d0824a541434024f9521f583d87028b8/content/renderer/renderer.sb

Ok, can we verify this again on 10.13 and then mark this fixed?

Marking Fixed.

Thanks!

let me re ask my previous question when we can expect this life?

re comment 65:  It'll be live in the next release of Chrome 62.x.  And,  it's already a part of Chrome 63.x (dev channel). 

Ok, and when will be the 62 release of chrome? Id there a Date?

#67 - there is no good answer. Here are some details to make up your own answer -
- Chrome is released every six weeks or so.
- Estimated release dates for major versions can be found at https://www.chromium.org/developers/calendar
- Patch releases (releases that only update the fourth version component - the x in 62.0.3202.x) are not regularly released, but only if there is a critical need (a high severity security vulnerability fix, a browser issue that affects a high percentage of the Chrome user base, a web issue that affects high profile websites, or a lot of websites). Since macOS is not used by a high percentage of the Chrome user base (also as a result of not being used by a high percentage of the computer users), the priority is probably lower and does not justify releasing a patch release only for this fix, I reckon. If there happens to be a patch release (there usually is at least one), it will be included in it.
You can follow https://chromereleases.googleblog.com/ for release announcements.

Tested this issue on Mac 10.12.6 & 10.13 using chrome#62.0.3202.75 as per C#4,26,49 and observed timezone is displayed correctly when the system time zone is changed which is as intended behavior.Hence adding TE-Verified labels.

Please find the attached screencast on mac 10.13.

Thanks..!

Deleted: 773532-10.13.mp4 2.4 MB

	773532-10.13.mp4 2.4 MB View Download

This issue is still affecting build 64 of Chromium.

In gmail web UI, the times displayed are offset by 2 hours.  This does not happen on Safari.

Going to the test page (http://jungshik.github.io/cr/bugs/520783.html), I get this:

toString: Mon Nov 13 2017 07:48:47 GMT+0000 (UTC)
getTimezoneOffset: 0
valueOf/1000/3600: 419599.81305861106
Intl datetime with local tz: Nov 13, 2017, 9:48 AM Israel Standard Time
Intl datetime with UTC: Nov 13, 2017, 7:48 AM Coordinated Universal Time
Intl datetime with tz = Honolulu: Nov 12, 2017, 9:48 PM Hawaii-Aleutian Standard Time
Intl datetime with tz = Calcutta : Nov 13, 2017, 1:18 PM India Standard Time
Intl.DateTimeFormat("en-US").resolvedOptions().timeZone: Asia/Jerusalem


My Chromium build: Version 64.0.3268.0 (Developer Build) (64-bit)

OS info: 17.0.0 Darwin Kernel Version 17.0.0: Thu Aug 24 21:48:19 PDT 2017; root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64

Adding to my previous comment (showing the this issue is actually not resolved):

Machine details - MacOS High Sierra 10.13.1, Mac Mini late 2014.

Does the issue seem to be specific to High Sierra? And you're testing this in an official Google Chrome build, or in a Chromium build?

I found the problem on 10.13: deny file-read-data /private/var/db/timezone/tz/2017c.1.0/zoneinfo/UTC

Thanks for reporting this problem. As clarification, this shouldn't affect any Google Chrome builds, as the regression is in the new "v2 sandbox" which is currently being tested in Chromium builds but isn't activated for any official builds.

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

commit 3ff3ecaba63ca582427cb2d48a207b6652e07ef8
Author: Greg Kerr <kerrnel@chromium.org>
Date: Mon Nov 13 20:09:12 2017

macOS V2 Sandbox: Allow timezone folder in 10.13.

The timezones in 10.13 moved to a new location, so this adds that path
for 10.13 to the V2 sandbox profile.

Bug:  773532 
Change-Id: I7944d4fb7a34869c80337fa8109a1a830a663671
Reviewed-on: https://chromium-review.googlesource.com/767108
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Greg Kerr <kerrnel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516019}
[modify] https://crrev.com/3ff3ecaba63ca582427cb2d48a207b6652e07ef8/services/service_manager/sandbox/mac/renderer_v2.sb

Can confirm the issue is now resolved, still in Chromium Version 64.0.3268.0 (Developer Build) (64-bit)

(this is in build 516185, from 1hr ago, obtained from https://download-chromium.appspot.com)

Thanks for looking into this, glad to be of help.

Hi! I'm still seeing this issue in Google Chrome as well as Chrome Canary, on macOS High Sierra.

Here are the version numbers I'm running:

  Google Chrome: 64.0.3282.167 (Official Build) (64-bit), V8 6.4.388.45
  Google Chrome Canary: 66.0.3353.0 (Official Build) canary (64-bit), V8 6.6.290
  macOS: macOS 10.13.3 (17D47)

Report from http://jungshik.github.io/cr/bugs/520783.html after manually setting system time zone to New York:

  toString: Fri Feb 23 2018 20:12:36 GMT+0000 (UTC)
  getTimezoneOffset: 0
  valueOf/1000/3600: 422060.21021499997
  Intl datetime with local tz: Feb 23, 2018, 3:12 PM Eastern Standard Time
  Intl datetime with UTC: Feb 23, 2018, 8:12 PM Coordinated Universal Time
  Intl datetime with tz = Honolulu: Feb 23, 2018, 10:12 AM Hawaii-Aleutian Standard Time
  Intl datetime with tz = Calcutta : Feb 24, 2018, 1:42 AM India Standard Time
  Intl.DateTimeFormat("en-US").resolvedOptions().timeZone: America/New_York

Let me know if there's anything I can run to help debug. Thanks!

Interesting, I can't reproduce. Also what's odd is that your toString is in UTC but the local tz is in EST. Does anyone familiar with those javascript APIs know what this could be?

Yeah, it looks like the Intl APIs are correct but the regular Date ones are not.

And to be extra clear about the repro: the steps are the same as the OP's (the system timezone needs to be changed manually first).

Can you file a new bug for this issue so it doesn't get lost?

For sure! I've opened a new issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=818249

Thanks!