Bug 263841 - need a central, central-time city in timezone selector GUI
need a central, central-time city in timezone selector GUI
Product: Fedora
Classification: Fedora
Component: tzdata (Show other bugs)
All All
medium Severity low
: ---
: ---
Assigned To: Petr Machata
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-08-29 11:48 EDT by Michael Williamson
Modified: 2015-05-04 21:33 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-30 07:51:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Williamson 2007-08-29 11:48:24 EDT
Description of problem:

Upon install, anaconda's timezone selection GUI does not have an obvious city
for central time.  There seems to be a big open spot in the central USA with no
cities to select, and Chicago is just too far over to be "obviously" central. 
Please consider adding a central-time city actually in the geographic central
USA.  I suggest Kansas City, Kansas or Dallas, Texas.  

Along the same lines, is there really reason to have that many cities clustered
together on the map just to the southeast of Chigago?
Comment 1 Petr Machata 2007-08-30 07:51:02 EDT
The cities clustered just below Chicago are mosty part of Indiana, where there
were a lot of changes, DST-wise as well as zone-wise, historically as well as
recently.  We need to treat each city separately because zoneinfo (tzdata) are
are also historical database, and historical records for these cities differ.

So the reason why only Chicago is here to represent Central time is that there
were no historical breakups in this region that would warrant stuffing more
cities into the database.

Actually, what zoneinfo does, is that it provides generic identifiers, that only
happen to match names of the cities (because it's convenient from the
maintenance point of view).  If there is a need e.g. to display exact
geographical, country or state boundaries, list all cities, filter cities
according to some rule (e.g. to address the Chicago cluster which may be
irrelevant today), this calls for a project that would define and *maintain*
independent list that maps to the generic zoneinfo identifiers.  I don't see
this going to happen inside upstream zoneinfo project.

Note You need to log in before you can comment on or make changes to this bug.