Closed peterkaminski closed 3 years ago
P.S., thanks, it's a nice app!
Thanks for filing that bug with jstimezonedetect.
Unfortunately, it's likely that this is an issue with Chrome. E.g. ChromeOS can know when the network changes, detect a new time zone, and update its UI, but that change may not be propagated to web pages immediately.
It's also a hard bug to test. If you encounter this bug again, could you try running this in the javascript console (Ctrl+Shift+J in a Chrome tab)?
Date().toString()
And see whether it reports your old time or new time.
I am now home. I closed chromecalclock there, and reopened it here, but I haven't changed my time zone settings yet.
jstimezonedetect and chromecalclock report my timezone as America/Los_Angeles (which is GMT-8, and also, coincidentally, where my home is), even though my ChromeOS timezone is manually set to GMT-5. So, even though chromecalclock was displaying time according to my OS timezone settings when I was remote, either closing the app and reopening it, or (presumably less likely) moving geographically to a new timezone, caused it to reset to displaying GMT-8.
On my Chromebook, Date().toString()
in the Chrome console reports a the correct time according to my ChromeOS time settings, that ends in "GMT-0500 (EST)", so it's got the same timezone as my ChromeOS settings.
My suggestion would be to add a new settings item, "Default time zone", which would be similar to the "Extra time zones" section, and just above it. You could have a selection or checkbox for "Auto-detect" which would do the same action as present, but could be manually overridden so the display could be corrected manually.
The settings dialog is getting full, though -- I'm not sure how you would resolve needing more vertical space.
A different solution would be to not special-case clock0, and include it in the "add clock" and "set time zone" controls.
Added a pull request, #7, with the start of the settings changes.
I think this bug in Chrome is causing what you're seeing: Issue 406382: After changing timezone, Date.toLocaleTimeString() returns in old timezone.
Sounds like the underlying Chrome bug has been fixed.
When I traveled to another timezone, I had my Time/Date settings set to automatically update timezone, which it did. The timezone detection library didn't change, though, so Calendar Clock displayed the wrong timezone. Setting the timezone manually fixed the problem, but it's suboptimal to have to set the timezone manually.
I filed this issue for the timezone detection library: https://bitbucket.org/pellepim/jstimezonedetect/issues/134/timezone-detection-incorrect