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 519823 - Cities associated with wrong timezone
Cities associated with wrong timezone
Product: gnome-panel
Classification: Other
Component: clock
Other All
: Normal normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 522484 523686 525917 (view as bug list)
Depends on: 525451
Reported: 2008-03-01 23:46 UTC by Andrew Starr-Bochicchio
Modified: 2015-11-14 16:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22

patch to make sure we at least get the country right (9.03 KB, patch)
2008-03-31 22:24 UTC, Dan Winship
none Details | Review
Disables the guessing of the timezone (user has to pick) (775 bytes, patch)
2008-04-03 19:07 UTC, Simos Xenitellis
none Details | Review
updated timezone-guessing patch based on 526015 (22.70 KB, patch)
2008-04-04 19:14 UTC, Dan Winship
committed Details | Review

Description Andrew Starr-Bochicchio 2008-03-01 23:46:36 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."

"I chose Bombay/Santacrus as the location, and it shows Asia/Karachi. The right timezone for this is Asia/Calcutta."

"In my case, when one searches for Eugene, OR, it sets the timezone to Mountain time, when it should be Pacific time."

"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."

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."

"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"

Steps to reproduce:

Actual results:

Expected results:

Does this happen every time?

Other information:
Comment 1 Sebastien Bacher 2008-03-12 18:45:47 UTC
Similar bugs for other locations:

The importance should maybe be raised, that seems to be a frequent user complain
Comment 2 Mary Gardiner 2008-03-15 21:56:29 UTC
From Launchpad, apparently the code is simply dividing the world into vertical 'stripes' and each one is a timezone: 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, shows that very few countries have their timezones set up absolutely determined by longitude, most are using a combination of longitude and political boundaries.
Comment 3 Simos Xenitellis 2008-03-23 18:57:24 UTC
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.

Comment 4 tao 2008-03-27 23:09:33 UTC
Wouldn't it be better to have the timezone be part of the xml-file?  That way the timezone could still be automatic.
Comment 5 shirish agarwal 2008-03-28 07:26:12 UTC
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 :-

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 :(
Comment 6 Simos Xenitellis 2008-03-28 14:12:51 UTC
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).
Comment 7 Matthias Clasen 2008-03-31 18:05:05 UTC
I would agree to this approach. 

Just need to find a volunteer to write the patches...
Comment 8 Dan Winship 2008-03-31 22:24:50 UTC
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.
Comment 9 Dan Winship 2008-03-31 22:57:51 UTC
(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.
Comment 10 Vincent Untz 2008-04-03 15:54:18 UTC
*** Bug 525917 has been marked as a duplicate of this bug. ***
Comment 11 Simos Xenitellis 2008-04-03 19:07:24 UTC
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.
Comment 12 Dan Winship 2008-04-04 19:14:04 UTC
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.
Comment 13 Simos Xenitellis 2008-04-04 20:00:23 UTC
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.
Comment 14 Dan Winship 2008-04-04 20:58:07 UTC
I believe the patch is ready, and yes, I'd like it to get into GNOME 2.22.1.
Comment 15 Vincent Untz 2008-04-07 09:58:06 UTC
I've committed all of Dan's patches. Thanks a lot, Dan!
Comment 16 Simos Xenitellis 2008-04-07 11:02:32 UTC
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).
Comment 17 Vincent Untz 2008-04-07 13:30:22 UTC
*** Bug 522484 has been marked as a duplicate of this bug. ***
Comment 18 Vincent Untz 2008-04-08 10:24:46 UTC
*** Bug 523686 has been marked as a duplicate of this bug. ***