After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794288 - Automatic Time Zone sets wrong zone
Automatic Time Zone sets wrong zone
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: datetime
3.26.x
Other Linux
: Normal normal
: ---
Assigned To: Kalev Lember
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2018-03-13 13:12 UTC by Jeff Needle
Modified: 2018-03-22 15:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
datetime: Add debug to timezone monitor (2.97 KB, patch)
2018-03-22 15:24 UTC, Bastien Nocera
committed Details | Review

Description Jeff Needle 2018-03-13 13:12:10 UTC
I have 2 desktop systems running latest Fedora 27 and both are set to "Automatic Time Zone".  Both are wired systems connected to the same hub and neither has wireless and neither has a VPN set up.  One system correctly set to EDT (New York, United States).  The other inexplicably sets to CST (Shanghai).

curl "https://location.services.mozilla.com/v1/geolocate?key=geoclue" returns:
{"location": {"lat": 42.7305, "lng": -71.4958}, "accuracy": 10000.0} on both systems and that is correct.  No clue why one system thinks it is in Shanghai.  Heck, it wasn't even manufactured there back in 2002 when I first got it.
Comment 1 Jeff Needle 2018-03-14 15:25:15 UTC
OK, this is kind of annoying but today I turned off location services and tried again and Automatic Time Zone worked.  Then I turned it back on again and it was still working.  Our resident IT guy says that we had an egress issue where geoiplookup.net was showing our address as China / Beijing (https://whatismyipaddress.com/ip/209.132.182.104) while whois shows it in the US.  So basically IT gave me some advice and I turned it off and turned it back on again and it works now.  Shall we simply close this as "working as expected.  Internet broken."?
Comment 2 Kalev Lember 2018-03-14 15:33:59 UTC
I'd say so. Thanks for reporting it in any case!
Comment 3 Bastien Nocera 2018-03-14 15:58:53 UTC
I'll reopen this, as we'd need at least some debug added to the plugin so that we know for sure what the issue is, for example, being able to know which location we get back from Geoclue, which "nearest location" we ended up selecting in tzid/libgweather's databases, and which timezone ultimately gets associated to that.

We might also want to have a clearer path to reporting problems like this. "The database is broken" and throwing hands up in the air isn't quite what we're aiming for, and it looks especially bad if we don't even know how to contribute to the databases we use.
Comment 4 Bastien Nocera 2018-03-22 15:24:45 UTC
Created attachment 370014 [details] [review]
datetime: Add debug to timezone monitor

To make debugging issues with the automatic timezone feature easier.
Comment 5 Kalev Lember 2018-03-22 15:26:42 UTC
Review of attachment 370014 [details] [review]:

Looks good to me! Thanks.
Comment 6 Bastien Nocera 2018-03-22 15:32:36 UTC
Attachment 370014 [details] pushed as f782918 - datetime: Add debug to timezone monitor