> However, I suspect that the mechanism is in fact the same. That there is similar code used in ChromeOS and Chrome on other OS's to set the timezone based on location, and this is the root cause in every case.

There are multiple potential failure points for this issue. One of them would have the same or a similar root cause as  bug 766916  (which I suspect, in turn, caused by  bug 754053 ), but there are other possible failure points, which is why I asked you to file a separate bug. 

1. The automatic timezone detection per geo-IP somehow fails to set the timezone at the "Linux layer", by which I mean '/etc/localtime' is not made a symlink to the correct zonefile in /usr/share/zoneinfo (for America/Los_Angles, it'd be /usr/share/zoneinfo/America/Los_Angeles). 

By any chance, is your Chromebook under the control of enterprise policy? I'm cc'ing alemate@ and xiyuan@ for that. 

2. #1 works fine, but ICU fails to read the current timezone ID from /etc/localtime and its symlink. That's  bug 766916  . 

On Chrome OS 63.x canary, I found that /etc/localtime is not a symlink to /usr/share/zoneinfo/<Olson timezone id> but a symlink to /var/lib/.../localtime which is in turn a symlink to /usr/share/zoneinfo/<Olson timezone id>.   This may get ICU's timezone detection to misbehave (it uses readlink()
 
 



On two Chrome OS devices (one with 63.x canary and the other with 61.x beta), I 

On two Chrome OS devices (one with 63.x canary and the other with 61.x beta), I 
have a rather interesting experience. 

I turn off the automatic timezone detection in Settings and changed the timezone manually to Europe/London. Then, I turn back on the automatic timezone detection. 

On Pixel with 63.x canary, the timezone in settings page is changed back to 'America/Los_Angelest' (the correct timezone for me) in a couple of seconds. /etc/localtime is resolved to /usr/share/zoneinfo/America/Los_Angeles as well (with an indirection via /var/lib/... )

On another Chrome OS device with 61.x beta, the timezone in settings page remained Europe/London.  A long while (say 5 minutes??) or some further steps (I forgot what exactly I did. I did it 7 hours ago. I'll try again), somehow it's changed to America/Los_Angeles. 

I haven't unlocked this device so that I don't know the resolved target of  /etc/localtime. I'll unlock and see that file. 

> By any chance, is your Chromebook under the control of enterprise policy?

No.

> On another Chrome OS device with 61.x beta, the timezone in settings page remained Europe/London.  A long while (say 5 minutes??) or some further steps (I forgot what exactly I did. I did it 7 hours ago. I'll try again), somehow it's changed to America/Los_Angeles. 

Hmm, this time on the same Chromebook where it took very long, the same 3-step procedure ( 1. turning off the automatic setting, 2. a manual change to a timezone far off 3. turning back on the automatic setting) got me back to the correct timezone (America/Los_Angeles) within a second or so. 

It's Chrome OS 61.0.3163.80. 

 

> On Pixel with 63.x canary, the timezone in settings page is changed back to 'America/Los_Angelest' (the correct timezone for me) in a couple of seconds. /etc/localtime is resolved to /usr/share/zoneinfo/America/Los_Angeles as well (with an indirection via /var/lib/... )

On this device, /etc/localtime => /var/lib/timezone/localtime => /usr/share/zoneinfo/<Olson ID> (where <Olson ID> is America/Los_Angeles in my case). 
 

anwaya@:  what happens if you turn off the automatic timezone detection and turn it back on?  

Is the following your current version ? 
> Chrome version: 60.0.3112.114  Channel: stable

+vapier to ask about the following symlink chain I found (comment 5): 

/etc/localtime => /var/lib/timezone/localtime => /usr/share/zoneinfo/<Olson ID> (where <Olson ID> is America/Los_Angeles in my case). 

Although the above does not affect the (correct) behavior on my test device (Pixel) and it's not likely that that's the cause of this bug, I'm wondering if the above symlink chain is new in recent versions of Chrome OS. 

On typical Linux machines, /etc/localtime is a direct symlink to a zonefile. 

/etc/localtime => /usr/share/zoneinfo/<Olson Timezoe ID>  (e.g. up to Ubuntu 14.x)
/etc/localtime => ..//usr/share/zoneinfo/<Olson Timezoe ID>  (e.g all the latest/recent versions of Ubuntu, RHEL, SuSE linux). 

(see  bug 754053  ). 

for the purposes of this bug, the /etc/localtime symlink has been there "forever" (i can look back to see when it started if anyone cares, but it won't change things).  / is a read-only partition, so there's no way we could update /etc/localtime, so it needs to point to somewhere we can change.

Chrome is then responsible for updating the /var/lib path:
https://cs.chromium.org/chromium/src/chromeos/settings/timezone_settings.cc?sq=package:chromium&dr=C&l=240

but the rest of the code continues to look at /etc/localtime.

we can't use bind mounts because so many paths rely on creating unique mount namespaces.

The issue has gone away today. But when it was present, it was definitely annoying.

Replying to #c6:

> what happens if you turn off the automatic timezone detection and turn it back on?  

It didn't help: it would go back to Chicago. I tried setting the correct zone manually in Settings and then switching back to Automatic, but it still went back to Chicago.

> Is the following your current version ? 
> > Chrome version: 60.0.3112.114  Channel: stable

Yes. 

Thanks a lot, Mike for the explanation. 

anwaya@ : thanks. So, you're ok now, aren't you? 


+jim.dantin@gmail.com who mentioned the following thread: 
 
https://productforums.google.com/forum/#!topic/chromebook-central/BqINRDSXa1w;context-place=forum/chromebook-central

Jim, do you still have this issue?   

> anwaya@ : thanks. So, you're ok now, aren't you?

For now. But issues which come and go are not resolved. I could tell you exactly how I learned this principle, and what it took to resolve the issue at that time, but you'd need to buy me a beer or three.

+jshin@chromium.com I have never had the issue myself. I have tried to debug/help quite a few users on CBC, however.

As you both have noted, the issue comes and goes with no reliable fix/workaround. Sometimes rebooting helps, sometimes manual settings work.

Travelling with a sleeping device from one timezone to another seems like a triggering event. 

> Travelling with a sleeping device from one timezone to another seems like a triggering event. 

The only recent trip I've made where this could have happened was from Los Angeles to Detroit and back, but that skipped over both the Central and Mountain timezones. Could Chicago be some kind of default in this situation? A test of the skipped zone branch would involve going from (say) Denver to Houston. If it's any sleep with a zone change,  Los Angeles to Phoenix (and back) woud be comparable. Those are the kinds of test. Possibly using shipping.

> issues which come and go are not resolved.

of course, not. I never said that this issue is resolved. ;-) 

> Travelling with a sleeping device from one timezone to another seems like a triggering event. 

Thanks, Jim.  I wonder if there's a way to emulate that without actually travelling. 

> I wonder if there's a way to emulate that without actually travelling. 

Once more: shipping. Fedex a device to a friend/colleague in another timezone. Let them boot it and charge it, put it to sleep, and ship it back. 

I wonder if this is due to a race somewhere under a certain condition. 

We didn't have a lock around ICU timezone API calls (detectHostTImezone, createDefault, adoptDefault). They're not thread-safe, but we're pretty sure that they're called in a single thread. That may not be the case. 

https://cs.chromium.org/chromium/src/services/device/time_zone_monitor/time_zone_monitor.cc?rcl=940098b0c36f2048b1c813e8ba0af939365b48e0&l=30

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/time_zone_monitor/TimeZoneMonitorClient.cpp?l=63

Given that timezone change is very rare for the vast majority of users, we'd better be safe, IMHO. 

>  We didn't have a lock around ICU timezone API calls (detectHostTImezone, createDefault, adoptDefault). They're not thread-safe

Actually, createDefault() is fine. 

This isn't likely to be related to the Settings UI. Not sure how to triage it though.

temporarily setting to UI>Settings until we know the root cause.

It's not going to get triaged correctly at UI>Settings since I don't know anything about the implementation; it's not a bug in the "Settings UI" per-se, but the underlying implementation.

Assigning -> abodenha@ to triage since we don't have a good component for this (or at least I don't know what it should be; OS>Systems ?).

> >  We didn't have a lock around ICU timezone API calls (detectHostTImezone, createDefault, adoptDefault). They're not thread-safe

> Actually, createDefault() is fine

And, Chrome OS does not call adoptDefault in the timezone monitor code. 

Where's the code to detect the timezone automatically based on geoIP/location and set the OS timezone accordingly ( by changing the symlink target of /var/lib/timezone/localtime )?  I didn't look for it hard enough, but at least I don't find it in src/chromeos/settings/timezone_settings.cc . 

Think the code is in chromeos/timezone/timezone_resolver.cc

Thanks, xiyuan !

Hmm...  chromeos/timezone/timezone_resolver.cc hasn't been touched recently except for some RPC API changes.