Bug 97192 - kworldclock: St Louis timezone is broken
Summary: kworldclock: St Louis timezone is broken
Status: RESOLVED FIXED
Alias: None
Product: kworldclock
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Matthias Hoelzer-Kluepfel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-16 23:15 UTC by Ben Burton
Modified: 2008-04-01 16:16 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Burton 2005-01-16 23:15:46 UTC
Version:            (using KDE KDE 3.3.2)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Received through the Debian BTS as #283958.

The timezone for St Louis (USA) is showing up as GMT, which is incorrect.

It seems St Louis was recently added to zone.tab as a result of #56511.  The trouble is that, as I understand it, timezone information is calculated by setting $TZ as the timezone name (e.g., America/St_Louis) and using the system timezone functions.  The system does not know of a timezone called America/St_Louis, and so GMT is assumed.

As I see it, you cannot add any city you like to zone.tab.  If the system timezone functions do not know about the city (e.g., it does not appear beneath /usr/share/zoneinfo/), then there is no way that the system can work out what the correct timezone is supposed to be.

I would suggest removing St Louis from zone.tab once more.

Thanks - Ben.
Comment 1 Brian Beck 2005-01-17 17:05:42 UTC
This may be a dumb idea, but could we change to zone.tab file in /usr/share/apps/kworldclock to a slightly different format? One like this

# Formal Name    Country    Province    Coordinates
Saint Louis      US         Missouri    +383738-0901152

Then using the coordinates kworldclock could deduce the timezone for that area, then with that knowledge determine the time.

The upshot to this change would be that we wouldn't be reliant on what is already in /usr/share/zoneinfo, so users could add any location as long as the coordinates are known.

Like I said, this idea may be dumb or just naive. So ignore me if it is.
Comment 2 Kurt Hindenburg 2005-12-19 07:03:18 UTC
SVN commit 489571 by hindenburg:

Update zone.tab from glibc-2.3.5 (v1.30).

Brian Beck: The format of this file is taken from glibc; it would be
unwise IMHO to change it.

BUG: 97192



 M  +88 -51    zone.tab  
Comment 3 Roland Latour 2008-04-01 16:16:50 UTC
Edited zone.tab. Duplicated the Los_Angeles line. Changed from:
US      +340308-1181434 America/Los_Angeles     Pacific Time      to:
US      +420600-1233500 America/Cave_Jct        Pacific Time

Shows up on map with GMT time! Tried to add a clock for my location.
Changed Timezone in dialog box from "America/Cave Jct" (!!) to
"America/Los Angeles", and Caption changed! to match timezone.

Bugreport shows this has been fixed, without any details. Plus, this
application shows no version number in "About". This is bound to make
bug tracking difficult. This bug is not about changing file format,
it is about timezone handling, which is clearly broken.