GNOME Bugzilla – Bug 519823
Cities associated with wrong timezone
Last modified: 2015-11-14 16:46:44 UTC
Please describe the problem: Multiplet cities are associated with wrong timezone in the clock applet. Some cases: "Nashville in Eastern Standard Time, or Kentucky/Monticello. In fact, Nashville is in Central Time, or Indiana/Chicago." https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/197085 "I chose Bombay/Santacrus as the location, and it shows Asia/Karachi. The right timezone for this is Asia/Calcutta." https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/196385 "In my case, when one searches for Eugene, OR, it sets the timezone to Mountain time, when it should be Pacific time." https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/196124 "However, when I went to add Pittsburgh, it associated the city with the America/Detroit timezone when it belongs America/New York timezone. The latitude and longitude are correct." https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/185190/ I have filed these all together as this seems to be more than a few incorect data points. "I don't think the problem actually lies with the tzdata itself. That surely is where it gets the actual timezone information, but it does not seem to be where it gets the city database from. In my example above, Eugene does not appear anywhere in the tzdata information that I can see. However, using the "location" setup in the clock, there is another database of cities somewhere, including latitude and longitude information for the city. This information is (apparently) used to determine the timezone that the city is in. This is where this bug appears." https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/196124 "matt felser wrote on 2008-02-17: After some exploration, the locations are drawn from an XML file in /usr/share/gnome-applets/gweather/Locations.xml. I checked the source of gnome-applets, but I could not find Locations.xml. What package would this be in? matt felser wrote on 2008-02-17: Or is refers to whatever LIBGWEATHER_LOCATIONS points to. However, I am inexperienced with programming in Ubuntu and I cannot trace it any further. Sebastien Bacher wrote on 2008-02-17: The source package is libgweather matt felser wrote on 2008-02-17: Thanks. I examined the XML file and nothing is out of order there. The latitude/longitude, IWIN, forecast, and radar codes are all correct. It seems that the problem is in the gnome-panel package, and not libgweather or gnome-applets. I do not see where the time zone is generated from. If it is parsed from the coordinates, then they issue may lie in that algorithm. Sebastien Bacher wrote on 2008-02-17: Thank you for your on that. Right there is similar bugs about other locations so that's likely a code issue which means the bug might not be that trivial" https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/185190/ Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Similar bugs for other locations: https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/200698 https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/199582 https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/199583 The importance should maybe be raised, that seems to be a frequent user complain
From Launchpad, apparently the code is simply dividing the world into vertical 'stripes' and each one is a timezone: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/185190/comments/12 Then the code calculates the nearest 'stripe' from the latitude and longitude of the city and assumes that that is the correct zone. This pretty much guarentees errors for all kinds of countries, particularly but not exclusively large ones like China, which 'should' span four timezones by longitude but actually uses only one. Examining a timezone map of the world, say, http://www.worldtimezone.com/ shows that very few countries have their timezones set up absolutely determined by longitude, most are using a combination of longitude and political boundaries.
This issue (wrong timezone when selecting your city) is likely to lead to negative publicity, considering political issues with neighboring countries (I was notified about this by several angry users). What I would recommend is not to try to autodetect the timezone for a city, but rather have the user select the timezone manually. I would consider this as a quick fix if we do not have something better, because distros like Ubuntu and Fedora are rolling out very soon. That is, when the user selects the city, the timezone entry does not get auto-filled.
Wouldn't it be better to have the timezone be part of the xml-file? That way the timezone could still be automatic.
I don't know what is the way out but it definitely irks me that I'm in the PKT or Pakistan time zone even though I entered correct Longitude and Latitude for Pune. A cursory google search gives me this :- http://www.timeanddate.com/worldclock/city.html?n=1038 Latitude: 18° 34' North Longitude: 73° 58' East Now this doesn't keep here, this is displayed to me when I'm using any and all Instant Messaging services from Pidgin or other places. Just not the right thing to do :(
I think the first decision to make is whether to have some quick-fix (as I describe above) for this version of GNOME, which is going to hit the distributions in April/May. My view is that in the clock UI, when you pick the city, it should not auto-guess the timezone. In usability terms is makes it awkward (the timezone list is huge), but we are spared the political headache. Northern Greek cities currently auto-get the timezone of the countries north of Greece. The current situation makes the promotion of GNOME to Greece rather harder. Indeed, a good solution is to have the timezone information in the Locations.xml file; each city can have a timezone, and in the absence of it, we could use the timezone of the parent (i.e. Country entry).
I would agree to this approach. Just need to find a volunteer to write the patches...
Created attachment 108377 [details] [review] patch to make sure we at least get the country right Assigning timezones to every single city in Locations.xml is going to take a while... But as a first step, we can at least make sure we pick a timezone in the right country.
(In reply to comment #8) > Assigning timezones to every single city in Locations.xml is going to take a > while... Hm... actually, it's mostly only one per country, plus one per US state, plus another few dozen for the remaining very large countries. Stay tuned.
*** Bug 525917 has been marked as a duplicate of this bug. ***
Created attachment 108564 [details] [review] Disables the guessing of the timezone (user has to pick) We simply disable the guessing of the timezone. The user has to pick the timezone manually from the list.
Created attachment 108626 [details] [review] updated timezone-guessing patch based on 526015 Updated patch based on the new patch in bug 525451 which now includes timezone hints for countries, states, and some cities, and also updated to use the patch from bug 526015 that moves the Locations.xml parsing to libgweather.
Dan, are you aiming to get the patch in comment #12 ready for GNOME 2.22.1 (~3-days time)? If you are, I am happy to test it so that it makes it in 2.22.1.
I believe the patch is ready, and yes, I'd like it to get into GNOME 2.22.1.
I've committed all of Dan's patches. Thanks a lot, Dan!
Thanks Dan! I tried it out with cities in Greece and Cyprus, and the correct timezone is selected (Europe/Athens, Asia/Nicosia, both currently at EEST+2).
*** Bug 522484 has been marked as a duplicate of this bug. ***
*** Bug 523686 has been marked as a duplicate of this bug. ***