Important detail from the other bug:

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

... which is odd.

Not completely sure, but from reading through some of the related bugs, it seems to me like the Intl APIs use timezone data from ICU, which was fixed separately (see https://bugs.chromium.org/p/chromium/issues/detail?id=754053).

The ICU code is a bit weird, I think it tries to parse the timezone from the symlink path (see linked ticket above). Chromium doesn't do this.

On the Chromium side, the fix for  bug 773532  (https://chromium.googlesource.com/chromium/src.git/+/3ff3ecaba63ca582427cb2d48a207b6652e07ef8%5E%21/) added the timezone directory as `/private/var/db/timezone`; however on my machine `/etc/localtime` is symlinked to `/var/db/timezone/zoneinfo/`, without the `/private` prefix.

That's odd. You're running 10.13 and /var/db isn't symlinked under /private?

Can you do ls -la /var in a shell?

Ahh, sorry, `/var` is symlinked to `/private/var`. These are the symlinks I'm seeing:

> ls -la /etc/localtime
lrwxr-xr-x 1 root wheel 45 Mar  2 12:32 /etc/localtime -> /var/db/timezone/zoneinfo/America/Vancouver
> ls -la /var
lrwxr-xr-x 1 root wheel 11 Jan  8 16:27 /var -> private/var
> ls -la /etc
lrwxr-xr-x 1 root wheel 11 Jan  8 16:27 /etc -> private/etc

I tried running Chrome with the `--enable-sandbox-logging` flag and didn't see anything in syslogs (not sure I'm doing something wrong there though); but if I run with `--no-sandbox` I don't see this issue.

I see the same thing. Annoying that macOS symlinks to something that's a symlink itself. However, the sandbox only understands absolute paths. I might need to add a rule like:

(allow file-read-metadata "/var/db/timezone")) 

so that it can stat the symlink.

From the V1 profile: ;  https://crbug.com/754280 
(if (param-true? macos-1013)
  (begin (allow file-read-metadata (path "/private/var/db/timezone/zoneinfo"))
         (allow file-read-data (subpath "/usr/share/zoneinfo.default")))
  (allow file-read-data (subpath "/usr/share/zoneinfo")))

macOS changed the timezone path once more ?? 

> "it looks like the Intl APIs are correct but the regular Date ones are not.

Thanks to  bug v8:6031  being fixed recently, non-Intl API (Date.toString() ) would be correct, too, in ToT without this issue fixed :-). 

>  I think it tries to parse the timezone from the symlink path (see linked ticket above).

The lack of a standard API to get the Olson timezone id in effect forced ICU to do some interesting dance to get the timezone info. 

SO do we need to land a fix for this? Is it a valid issue or just something up with specific machine?

I don't think this is an issue with specific machines, but if I read correctly #8 was commenting that  bug 6031  being fixed yesterday would fix this as well.

re: comment 10/11: Yes, what axing@ wrote is what I meant. 

However, I can't reproduce the issue when I tried 
http://jungshik.github.io/cr/bugs/520783.html. 

1. Go the the above page
2. Change the system timezone
3. Click on 'recheck' button
4. Change the timezone once more
5. Click on 'recheck' button. 

Both toString() and toLocaleString() have the correct timezone. 

I also tried that in JS Console (as in the bug report) and it just works fine, too. 

I'm on macOS 10.13.3 and Chrome 64.0.3282.140.  

When verifying that  bug 773532  was fixed, I took the same steps (IIRC). 

I noticed that my Chrome is a bit behind the latest stable release. Let me try after updating. 

After updating, I have Chrome  65.0.3325.146 and still cannot reproduce the bug.  And both axing@ and I am on macOS 10.13.3.

Chrome 65.0.3325.146 does NOT turn on '--icu-timezone-data' flag for v8 and the output from 'new Date().toString' confirms that (timezone name is 3-4 letter abbreviation instead of 'Pacific Standard Time' on mac/Linux/Android/CrOS). 

I don't know why I can't reproduce it. 

/var, /private/var, etc symlinks are identical to that reported in comment 4. 

axing@: as a temporary work around  bug v8:6031  was fixed only in 67.x), you can try passing the following command line flag to Chrome:

--js-flags="--icu-timezone-data" 

kerrnel@: can you reproduce it?  If so, you may make a change you have in mind and merge to earlier branches.   67.x branch would not need it because icu-timezone-data flag is ON by default, though. 

jshin@, no I cannot reproduce this either so I really don't know how to fix it. Has anyone but the reporter repro-ed?

kerrnel@: we've gotten a few bug reports from users that are caused by this issue; I've asked a few colleagues and they can repro as well.

However, since it seems like this will be fixed in 67, it might not be worth it to put a lot of effort into this. I'd still be happy to help debug more though since I have a repro.

Thanks. Can you launch Chrome with --enable-sandbox-logging and check Console for error output? You'll want to filter on 'Sandbox' and 'Chrome'.

Oof, yeah, I see a bunch of errors of this sort:

Sandbox: Google Chrome He(34013) deny(1) file-read-data /private/var/db/timezone/tz/2018c.1.0/zoneinfo/UTC

Also for paths /etc and /var. I've attached full filtered logs.

Deleted: sandbox.log 16.9 KB

sandbox.log 16.9 KB View Download

Thanks. If this is already fixed in M-67 I'm not sure we should do anything else about this, since 66 is already Beta.

It would be great to get this fixed faster, we get approximately one email every day from our user-base complaining about this.

Hmm.... I've just reproduced it.  Because I'm not sure how this was triggered this time (but not previously when I wrote my comments - comment 10), I'm writing exactly what I did to get this issue triggered. 

With Chrome open (a lot of tabs), I did the following:

1. Change the OS tz to America/New_York (from America/Los_Angeles)
2. Change it back to America/Los_Angelese
2. Download a file https://bugs.chromium.org/p/chromium/issues/detail?id=288697#c12
3. Open it from the download strip (the default html viewer is Chrome on my Mac so that a new tab is created to open the file)
4. The tz is UTC (offset = 0) instead of America/Los_Angeles (UTC-7).
5. Open a new tab and load http://jungshik.github.io/cr/bugs/520783.html : the same issue here

Chrome version:
 65.0.3325.146

This is really strange because we tested this scenario (new tab scenario) before after kerrnel@ opened up more file access for timezone retrieval. Back then, it worked. 

Anyway, I think we'd better fix it for M65 by revising sandbox rules for tz-related files/dirs. 

Once icu-timezone-data option is completely gone in v8 (it's on by default in 67.x branch but the flag is still around), we can change the sb rules to disallow access to them. 

In  bug 773532 , we tested it. 

Anyway, the following from SB log is interesting: 

Sandbox: Google Chrome He(34013) deny(1) file-read-data /private/var/db/timezone/tz/2018c.1.0/zoneinfo/UTC

2018c.1.0 is a reference to the latest IANA timezone database version (2018c). I don't remember seeing versioned subdirectories in /private/var/db/timezone before. IIRC, /private/var/db/timezone just has 'zoneinfo' subdirectory instead of 'tz/<tz db version>'. I could be wrong about this. 
    
Anyway, if I'm right and versioned subdirectories are new in the latest High Sierra subversion,  that may explain why this came back (even though we verified that it's fixed in  bug 773532  for High Sierra). 

And, this bug explains why my gmail timezone is completely off (for other reasons, I've   played with timezone changes recently). 

Indeed it appears the on disk format changed, we'll have to tweak the sandbox rules.

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

commit 3d6ecf141a0157cfd83844aef94630b2a6de8284
Author: Greg Kerr <kerrnel@chromium.org>
Date: Mon Mar 19 22:58:47 2018

macOS Sandbox: Add timezone subpath to profile.

This CL allows access to the entire timezone folder subpath, as macOS
has changed the layout of the timezone data on disk.

Bug:  818249 
Change-Id: Ied9b81977e0453616b72e74da86d4d67c211785b
Reviewed-on: https://chromium-review.googlesource.com/969617
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Greg Kerr <kerrnel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544197}
[modify] https://crrev.com/3d6ecf141a0157cfd83844aef94630b2a6de8284/services/service_manager/sandbox/mac/common_v2.sb
[modify] https://crrev.com/3d6ecf141a0157cfd83844aef94630b2a6de8284/services/service_manager/sandbox/mac/renderer.sb

This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

Approved for 66. Branch:3359

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

commit 58a2b3f914260d1b46940ec73de5f93ea991c9d0
Author: Greg Kerr <kerrnel@chromium.org>
Date: Fri Mar 23 23:29:02 2018

macOS Sandbox: Add timezone subpath to profile.

This CL allows access to the entire timezone folder subpath, as macOS
has changed the layout of the timezone data on disk.

Bug:  818249 
Change-Id: Ied9b81977e0453616b72e74da86d4d67c211785b
Reviewed-on: https://chromium-review.googlesource.com/969617
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Greg Kerr <kerrnel@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#544197}(cherry picked from commit 3d6ecf141a0157cfd83844aef94630b2a6de8284)
Reviewed-on: https://chromium-review.googlesource.com/978591
Reviewed-by: Greg Kerr <kerrnel@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#411}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/58a2b3f914260d1b46940ec73de5f93ea991c9d0/services/service_manager/sandbox/mac/common_v2.sb
[modify] https://crrev.com/58a2b3f914260d1b46940ec73de5f93ea991c9d0/services/service_manager/sandbox/mac/renderer.sb

Able to reproduce the issue on chrome reported version 64.0.3282.186 
Verified the fix on Mac 10.13.3 on Chrome version #66.0.3359.66 as per the comment#0
Attaching screen cast for reference.
Observed "Time and Timezone are correct when running `new Date()` each time"
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 818249.mp4 2.3 MB

	818249.mp4 2.3 MB View Download

 Issue 830918  has been merged into this issue.