Clock applet chooses wrong timezone for many cities (eg Pittsburgh, Beijing)

Has any action been taken? This seems like it should be a simple fix.

You are welcome to send a patch if you know what to change

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?

Or is refers to whatever LIBGWEATHER_LOCATIONS points to. However, I am inexperienced with programming in Ubuntu and I cannot trace it any further.

The source package is libgweather

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.

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

Marking confirmed to reduce triage.

Bug #197085, Bug #196385, and Bug #196124 all have similar issues.

Various bugs have been marked as duplicates of this one, but each refers to different cities. Documenting here the cities whose timezones are set incorrectly:

Eugene, OR (should be America/Los_Angeles, is set to America/Boise)
Portland, OR (should be America/Los_Angeles, is set to America/Vancouver)
Bombay/Santacrus (Asia/Karachi -> Asia/Calcutta)
Houston, TX (America/Monterrey -> America/Chicago)
Nashville, TN (America/Kentucky/Monticello -> America/Chicago)
St. Petersburg, Russia (Europe/Helsinki -> Europe/Moscow)

This may indicate multiple buggy entries in a database used for timezone mapping - or, it might suggest that the timezones are wrongly chosen based on which city is closest to the indicated city?

There is no database used for timezone mapping. There is a file called Locations.xml in libgweather that gives coordinates (among other things) for all locations. Somewhere, the coordinates are parsed incorrectly and mapped to the wrong timezones.

Yes, I've confirmed with a look at the code that there's no timezone-mapping database. The coordinates are not "parsed incorrectly", however; the trouble is this:

        for (l = zones; l; l = l->next) {
                ClockZoneInfo *info = l->data;
                clock_zoneinfo_get_coords (info, &zlat, &zlon);

                d = distance (lat, lon, zlat*M_PI/180.0, zlon*M_PI/180.0);

                if (d < dist) {
                        best = info;
                        dist = d;
                }
        }

The default timezone is calculated using nothing more than the raw distance to the cities after which the timezones are named. This is nonsense, this is obviously not how timezones are divided.

It would be far better for the location selector to not provide a default timezone at all, rather than configuring a wrong one.

This may become a non-issue if bug #199644 is fixed.

This certainly coincides with what I'm seeing. St Petersburg, Fl -> Houston, Tx = 787 miles. Clearly less than the 835 miles to Washington, DC.

Could something like ensuring the difference in longitude does not exceed a certain value (presumably somewhere in the 7.5 degree mark) help reduce (or even eliminate) this problem?

I.e. the code would read something like this (WARNING - untested... quite possibly not the correct syntax!):

        for (l = zones; l; l = l->next) {
                ClockZoneInfo *info = l->data;
                clock_zoneinfo_get_coords (info, &zlat, &zlon);

                d = distance (lat, lon, zlat*M_PI/180.0, zlon*M_PI/180.0);

                if (d < dist && abs(lon - zlon*M_PI/180.0) <= 7.5) {
                        best = info;
                        dist = d;
                }
        }

Erm... Ignore that last comment, It doesn't help in Pittsburgh's case anyway. :-(

It won't help in a lot of cases, it's really hard to come up with a heuristic that approximates the reality (see http://www.worldtimezone.com/ for what timezones actually look like) and does not get it wrong for many important cities. It needs to be looked up in a database, if it's going to be done this way.

For triagers: duplicates of this bug are frequently being filed against tzdata.

The obvious way to fix this would be to add a <timezone> entry to each city in Locations.xml. Unfortunately, that would be a very tedious task.

It may be better to add timezone information to locations where the distance code gives the incorrect result, and use the distance code as a default.

These two patches (for gnome-panel and libgweather trunks) may or may not lay the groundwork for solving this problem. As I proposed in my recent comment, the code allows for <timezone> tags in Locations.xml; I've added an example for San Diego.

Unfortunately, I can't figure out how to test this, due to the convoluted nature of gnome-panel applets; I can't keep the Ubuntu version of the clock applet from loading, and can't figure out how to load the more recent applet manually.

Of course, it is almost impossible to write code that works perfectly without any testing. The patches here should now work.

I'm not happy with this solution, however. It seems as though it requires a huge amount of work in updating Locations.xml, in a rather unfortunate way. It could certainly be possible to allow <timezone> entries for larger areas than just <location>s; for example, having one under a <state> or <country> apply to all cities and locations under that tag. However, I've attempted to change as little as possible with these patches, and so haven't gone about implementing such a system.

I still believe the correct solution for hardy is to not infer a timezone based on the city coordinates at all, and instead fix the timezone selector. Trying to get correct timezone settings for all locations is going to take a lot of time and effort - relying on this means we will still have users for hardy who get the wrong tz suggestion.

I agree that the solution is rather wanting, and believe that the timezone-guessing code is something that does not belong in any release. The idea of it not selecting a timezone at all is interesting: it would be very easy to do - I can make the patch if necessary - and wouldn't require any extra work.

However, I don't think upstream will accept that solution, whereas I think that having timezone data in the Locations.xml would be more likely to be accepted.

If someone who has the ability to actually apply any of the patches here would give an opinion on what should be done, I would be happy to implement the code (though I certainly can't enter the timezone data!).

I registered a bug on this when I couldn't find this one... bug # 199976

I know this has all been rehashed, but I think trying to add location / TZ data for each location entry is not going to work because the system doesn't select a location entry with the proper timezone in the first place.

I think an acceptable way to handle this time zone issue is to scrap the current location options and create a new location database with one entry per state / region / et al that fits into a timezone... currently there are many many many entries for the same time zones.

Right now there are lots of time zone choices that don't seem to have any logic as to why they were selected.

Coming from a US Perspective, I believe there are very few instances where timezones do not follow state borders. We should really have a tz entry for each state (maybe state capitals unless the state has two time zones) or reduce the number of entries overall in tzdata. Menominee, Wisconsin has a tz entry and I'm not sure why... we could remove all Mid-west USA entries except Chicago (which is CST) and I think people would figure it out.

It would also be helpful to display the timezone (even just the abbreviation) for each location ... so that I know that Rainy River or Chicago are both in the same Time Zone.

I'll explain my issue (below) with locations as they exist today:

Rainy River is on the border of Minnesota (USA) / Ontario (Canada) which is a very sparsely populated area with the two main industries being Farming (Sugar Beets) and Tourism (Fishing.) I only know about the Rainy River because I lived up there for a few years and fished the River but most of the state's residents do not know that as a location in our time zone.

and here specifically is my issue with the proximity based approach currently being applied... the system currently picks locations closer to the target city even though they're across time zones.

When picking a location for the city of Hibbing, Minnesota, USA -- the time zone defaults to America/Atikokan ... which is Eastern Standard Time (-5 GMT,) but all of Minnesota is Central Standard Time (-6 GMT.)

This is also a problem for Grand Marais, Minnesota -- which gets lumped in with the America/Thunder_Bay ... which is actually Canada, not USA. Grand Marais, Minnesota (not Michigan) is set to EST and it should be CST.

Minneapolis, Minnesota defaults to America/Rainy_River and it is further East than Hibbing.

So there is an issue somewhere with how cities are associated with time zones. It seems like the NE "arrowhead" of Minnesota is all set to Eastern Standard Time instead of Central Standard Time.

I would say that this issue will lead to embarrassing negative publicity, because it is common with neighboring countries to have some sort of animosity; seeing the timezone of some other country when you select your city is going to be bad.

What I recommend is to disable the auto-calculation of the timezone based on proximity of the city. The user would have to pick the timezone on her own. In usability terms it is cumbersome, but I find it as an easy quick-fix.

Russia, Saratov. We have Europe/Samara but this value is wrong. Right value is Europe/Moscow.
I guess many other locations will have wrong TZ in every country...

I can agree with Simos, but now in beta I see chooser... It's huge list!
May be just limit to calculated TZ as pre-selected value and 2 near values from west and south?
Just to cover right zone for sure but not showing whole list :)

Hm. But surely we must have a definite database. I guess it is somewhere at Nasa or google maps maybe...

According to Wikipedia there are 245 political entities in the world...
http://en.wikipedia.org/wiki/List_of_countries

... and only 193 with general international recognition....

So we've got 24 time zones...
A little history:

In 1878, Sir Sandford Fleming (1827–1915) developed the system of worldwide time zones that we still use today. He proposed that the world be divided into 24 time zones, each spaced 15º (fifteen degrees) of longitude apart (like 24 sections of an orange). He came to this idea because Earth completes a rotation every 24 hours and there are 360º of longitude, so each hour Earth rotates 1/24th of a circle or 15º.

So if this is the logic... why not just define each 24 hr time period... based on it's longitude...

Then define "political" exemptions which to the best of my research cover large geographical terroritories but are clearly defined by geo-political boundaries...

China is ONE timezone.
A few US States don't do timezones..
.Alaska (USA) should span a few timezones, but has been consolidated to 1.

And here's the current info on daylight savings time:
http://webexhibits.org/daylightsaving/g.html

Taking a look at this "large" problem and breaking it down to the most general concrete information and then defining exemptions .. has me looking at it this way...

1. define "true" time zones as represented by the only data we know to be consistant... Longitude.
-- The location of the user is always technically based on Longitude and Latitude... so this way we should be able to determine the "true" timezone.

2. define continental and sub-continental exemptions
-- define large exceptions... exemptions that span countries...
-- maybe this never happens

3. define country-wide timezones
-- basically which countries wrap themselves into a single timezone.
--- China

4. define regional exemptions
-- a regional exemption must fit inside of a country
--- aka alaska, usa
--- Navajo tribal nation
---- spans 3 states and participates in daylight savings time even though part of the nation lies in Arizona which does not participate.
--- Russia, 11 time-zones
---- permanent daylight savings time (so 1hr ahead of actual time zone)
--- other exemptions are the half and quarter-time modifications

5. unique / specific cirumstances...

In South Asia, if you follow a straight line west along the 27º latitude you will move back and forth across time zones: from Pakistan UTC +5 hours, India +5:30, Nepal +5:45, India (Sikkim) +5:30, China +8, Bhutan +6, India (Arunachal Pradesh) +5:30, Myanmar +6:30.

...
you could define the able based on the rules #2 and #3...
and define regional areas between two longitudinal points... within a specified country.

I think the key to the breakdown based on a descending order of priority (+):

Default Time Zone based on Longitude
Continent
Country of Origin
Region of County
City / Other / Specific

And the big news... has anybody seen this government ftp site with all of the timezone data defined?
ftp://elsie.nci.nih.gov/pub/

Okay but first you need to map the cities to the countries

I am guessing this would do the job
http://www.geodatasource.com/cities-free.html

The Slovakian city Kosice according to gnome calendar is in Europe/Uzhgorod timezone. What is wrong.

There is no need in listing cities that are wrong.

Almost all cities are incorrect, as the timezone that is nearest the position of the city is selected, not the one the place is really in.

Yeah, In my solution I didn't mean that you'd need to document each city's timezone -- only if there was something unique about it... you should be able to just map countries and potentially states / regions of countries... *IF* you needed anything at all.

Ryan

Same thing for me : France/Paris

San Antonio, TX and Killeen, TX are also incorrect. It selects America/Monterrey, which is not the same TZ.

This bug should really be addressed one way or another for 8.04. The consequences of relying on gnome-panel to choose the right time zone for you are potentially quite unfortunate.

Sebastien, what's your opinion on #199644 as a preliminary fix for this? I still believe that the current behavior is mis-optimizing for weather instead of time, and that fixing 199644 is therefore correct in its own right and also goes a long way to address the worst symptoms of this bug.

I don't think fixing bug #199644 will make a real difference for this one, most people pick a city because that's the first choice and they want to get weather informations

A patch to simply stop the automatic timezone selection would be quite easy. I can do this if it is needed.

Alternatively, I can improve my original patch to allow for timezones to be specified for entire countries/states. This would probably also be rather easy, though it would require that someone actually specify those timezones; I don't think I have the time to do that, but it might only require around 300 or fewer entries.

However, if a solution is needed for 8.04 - and I am also of the opinion that we do need one by then - then I'd prefer to have some input as to the best quick solution to this. Completely disabling the autoselection would probably be preferable to leaving the code as it is.

On Thu, Apr 03, 2008 at 09:06:02PM -0000, Sebastien Bacher wrote:
> I don't think fixing bug #199644 will make a real difference for this
> one, most people pick a city because that's the first choice and they
> want to get weather informations

I don't agree. I think a clock is a much more basic feature of the desktop
than weather reports, and think that emphasizing weather functionality at
the expense of more fundamental timekeeping is at the root of most of the
problems with the current applet.

Note that the applet is listed in the applet selector as "Clock", and the
preferences window is titled "Clock Preferences". Weather reports are, and
should be, a secondary concern, but the current structuring of the Location
editor does not reflect this.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

you have a point there, the timezone should be the first thing selected and the weather station should be an option but the issue is mainly the wrong timezone mapping, once that was fixed selecting a city should work alright.

The upstream bug has some first round of patches, one to workaround the issue and not select a timezone automatically, an another one is using the country codes to limit the timezone choices.

the bug has been fixed upstream now

OK... so it is now possible to set my local timezone (St Petersburg, Florida) correctly, but the second timezone I have configured (London, UK) is still showing up as BST + 5 even after manually selecting Europe/London as the timezone... Surely (since the UK has now changed for the summer) it should just be BST?

Upstream means fixed in GNOME's subversion, so it's not fixed yet in Ubuntu.

On Mon, Apr 07, 2008 at 03:58:39PM -0000, Richard J Foster wrote:

> OK... so it is now possible to set my local timezone (St Petersburg,
> Florida) correctly, but the second timezone I have configured (London,
> UK) is still showing up as BST + 5 even after manually selecting
> Europe/London as the timezone... Surely (since the UK has now changed
> for the summer) it should just be BST?

'+5' just refers to the time offset relative to your currently configured
timezone.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Ah... Thanks Steve. As long as that's the way it's supposed to work. I had briefly looked at the patch in GNOME's repository and couldn't see how it might "fix" that apparent weirdness, but unfortunately I didn't have the resources (or time) to build things locally and check for myself.

From my personal perspective, I find the "+5" distracting. At least with the settings I am using, the current presentation already includes the full local time for all configured locations. Except in the situation where I might need to know that it is "yesterday" or "tomorrow" the offset from local time doesn't appear to offer any benefit.

Is that a fair comment, or am I way off base (e.g. from a system administration perspective)?

This bug was fixed in the package gnome-panel - 1:2.22.1-0ubuntu1

---------------
gnome-panel (1:2.22.1-0ubuntu1) hardy; urgency=low

  * New upstream version:
    Panel
    - Convert username/login to UTF-8 in logout dialog
    - Fix applet processes not quitting when the applet is removed (lp: #195915)
    Misc
    - Remove old and useless files
    - Require gweather 2.22.1
    - Don't explicitly require libxml for the weather applet anymore
    Clock Applet
    - Fix crash when there are no locations available
    - Fix locations not appearing in the preferences dialog
    - Make find location window larger
    - Handle escape to close the dialog in the time/timezone dialogs
    - Fix various issues with adding/removing locations
    - Fix crash when PolicyKit helper can't be called (lp: #208791)
    - Fix crash when closing the calendar popup when a city is blinking
      on the map (lp: #200881, ##207954)
    - Improve the blinking on the map when clicking on various locations
    - Cleanups
    - Correctly redraw the map outline on expose events
    - Fix crash when the location doesn't have coordinates (lp: #201102)
    - Fix crash when updating locations while calendar popup is not shown
      (lp: #210470)
    - Fix initial visibility of the appointments to actually follow the
      state of the expander (lp: #206118)
    - Make sure we always use data from the right country (lp: #185190)
    - Show caldav appointments in the calendar
    - Ignore dbus errors when setting the time and there's no reply on the bus
      (lp: #207890)
    - Open evolution on the right day, in all timezones (lp: #66028)
    - Fix crash when an evolution-data-server dies (lp: #122590)
    - Correctly set time, even when DST is on (lp: #208598)
    - Handle multiple locations in the same timezone in a better way
    - Fix weather tooltip to show the real temperature and the apparent
      temperature, instead of only the apparent one (lp: #188183)
    - Do not lose the weather location information when changing the
      timezone of a location (lp: #200911)
    - Don't show weather information of the last location once it has been
      removed
    - Remove empty space on the left of the clock when there's no location
      (lp: #203691)
    - Potential fix for another crash in the calendar code
    - When adding a location, make it the current one if it makes sense
  * debian/control.in:
    - updated libgweather requirement
  * debian/patches/17_expose_wm_keybindings.patch:
    - dropped, the current version has some issues and need to be rework
      during next cycle (lp: #211112)
  * debian/patches/80_from_bugzilla_use_correct_current_timezone.patch:
    - dropped, fixed in the new version

 -- Sebastien Bacher <email address hidden> Tue, 08 Apr 2008 01:47:12 +0200

Northern Idaho in the US in in the "pacific" timezone (America/LosAngeles), see
  http://www.law.cornell.edu/uscode/15/usc_sec_15_00000264----000-.html
I noticed the problem for Moscow, Idaho, US.