Bug 130434

Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Still a problem in FC3

I consider implementing this (with a sensible number of yet-to-be-determined
cities that fill the greater gaps on the map) in the FC6 timeframe.

Yeah? Please include Boston; having to pick "New York" makes some folks around
here bitter. :)

Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Nothing has changed in FC5

Couldn't you just move?

Guy --

Matthew is poking fun of you and I can't say I blame him.  Here's the deal ...

1.  Not a Red Hat request or issue ...

You do not want to request this from Red Hat.  If you feel there should be an
additional city placed for the US CST6CDT (and there should be a
_damn_good_reason_ ;-), you need to contact Olson/Eggert and the Zoneinfo project:  
  http://www.twinsun.com/tz/tz-link.htm  

2.  Why Matthew is poking fun of you ...

What you're asking Red Hat to do is create an additional, *NON-STANDARD* entry
in the Olson Zoneinfo Database (i.e., the tree of files under
/usr/share/zoneinfo).  There are regularly "border cities" next to other
timezones, it happens.  If Red Hat (let alone Olson/Eggert) appeased everyone,
then the tree would be overly-bloated, and there's already enough of that (just
look at the tree ;-).    

Case-in-point ...

3.  UNIX/Linux admins should know their _official_ Zoneinfo path/region

As a UNIX/Linux administrator, it is _your_ responsibility to know the
_official_ entry (e.g., typically found in the /usr/share/zoneinfo/zone.tab
file) for your Olson Zoneinfo "path" for your "region."  As Matthew indirectly
stated, for Boston, this is "America/New_York".  If you are in "Central Time"
(CST6CDT observing DST), then this is "America/Chicago" (if you are not
observing DST, which is a continuing issue in Indiana, although some are
changing for 2007, then see the appropriate "America/Indiana/*" entries).

It's _not_ about "proximity" but the official zone you should choose.  The
Wikipedia article "List of tz zones" lists most of the _major_, _official_ Olson
Zoneinfo Database regions and their paths:  
  http://en.wikipedia.org/wiki/List_of_tz_zones_by_name  

Try _not_ to use anything but these, except as required or needed for
customization.  It's more for uniform standardization and convention (trust me,
I've been dealing with this on 24x7 operating, financial embedded VxWorks/Linux
systems sold overseas as well as the US now -- especially with the 2007 changes
here in the US that seem to be rippling, slowly, elsewhere ... sigh ;-), and the
efforts of Olson/Eggert -- adopted by most BSD/UNIX systems by the late '80s --
are _far_better_ than what most other approaches (including IETF, Microsoft,
etc... -- although Cisco has a good draft in the IETF process right now to
address both for DHCP).

For more on the Olson Zoneinfo Database, the corresponding Wikipedia article is
a good intro:  
  http://en.wikipedia.org/wiki/Zoneinfo  

Regarding #3, to reverse my prior statement, this really isn't a UNIX/Linux-only
issue.

If you live in the continental US, and observe the federally regulated DST,
these are the _only_ 4 Zoneinfo paths to know ...
  America/New_York
  America/Chicago
  America/Denver
  America/Los_Angeles

Are you on New York, Chicago, Denver or Los Angeles time?
So, again, to reverse my prior #3, it's not even a UNIX/Linux 'thang.  ;->

If this is "really" an issue, then the system|redhat-config-time, then maybe the
"please choose the closest city in your timezone" should have additional
disclaimers and/or help that some cities may differ from other, observed time in
the same timezone (e.g., Daylight Savings, DST).

Perhaps the description of the problem should be "a map isn't a useful way to
pick a timezone." If I click near my location on the map. I get the wrong timezone.
And, there is no feedback to tell me what map location the cursor has snapped
to, so I have to click one, notice it is wrong, click another, try to remember
which wrong one I clicked before, etc. This is worse in recent versions, which
enlarge an area of the map on the first click.
A simpler way to say that I am in the standard US Central timezone (without
having to know that Chicago also is) would be useful.

Guy --

You're still not seeing 2 facts ...

1.  You do _not_ have to pick from the map

Last time I checked (on RHL9/FC1/RHEL3 and FC3/RHEL4 as well as FC5/6), the
major Zoneinfo paths are listed as well as allowing you to choose on the map. 
And the tool clearly says "closest city in your timezone"

Microsoft Windows offers a map as well.

2.  These names come from Olson/Eggert

If you have a "problem" with the cities listed, then hit up the Zoneinfo project.

Now with that all said, if you want Red Hat to "simplify" the "default" map to
only list a subset of timezones to reduce confusion, that's an idea.  E.g., for
the continental US, remove the various Indiana cities (possibly regulating them
to a "2nd map" or separate "selector" box), leaving only the "official 4,"
that's an idea.

It might be nice for the tool to simplify the default selections to only those
paths that are 2 levels deep (e.g., America/New_York), and leave anything 3+
levels deep (e.g., America/Indiana/*) to a 2nd map and/or additional selector
box/list.

But that's all I'd argue for.  Let's not change "what works" for most people,
let alone what maps directly to the Olson Zoneinfo DB.  The more you try to
appease or try to accommodate their naivity/ignorance, the more issues you're
going to create.  ;->

BTW, when you "mouse over" the point on the map, it lists the Zoneinfo path
_and_ the "common convention."

E.g., when I put it over "Chicago", it shows ...
  America/Chicago - Central Time  

As such, Guy's nitpicking aside, I think this bug should be CLOSED/NOTABUG.

Guy -- if you want to open an enhancement that changes how the map operates
(such as in my previous post's suggestion), then go for it.  I do find it
annoying that it's difficult to choose Chicago because of all of the
non-standard Indiana cities, and they should be regulated to a secondary map
and/or list.

But this is not a bug. 

I'm not in a position to run an install right now, but I don't recall seeing a
text update when I moused around the map. If you say it's there, I'll take your
word for it. I do see it when I run s-c-time explicitly.
I still don't see a way to specifically pick Central timezone, except by
scrolling though a list alphabetized by location. Perhaps I'm missing something.

I was talking from the standpoint of redhat|system-config-time.  I assume
Anaconda uses the same, since it's all built on the same Python/GTK+ base IIRC.

Again, I think you keep missing the fact that we use Zoneinfo paths, not
arbitrary timezone strings.

Understand there is reason for that.  Also understand that the legacy POSIX TZ
string is (virtual) deprecated at this point.  There are some very
confusing/conflicting/ambiguous names worldwide using POSIX TZ -- e.g., neither
"Eastern Time" nor "EST" are North American only.  ;->

Zoneinfo paths are _always_ absolute.

A further enhancement to the redhat|system-config-time could be to sort by the
description field, instead of name (Zoneinfo path).  That would then list by the
description (e.g., Central Time) that you want.

Again, it's time to CLOSE/NOTABUG this entry.

Consider submitting a new "enhancement" entry with the following augmentations:
- Separate maps/lists of major timezones from eccentric/minor entries
- Offer the option to list/sort by description/common instead of Zoneinfo path
- Add additional static/context-sensitive help, description, etc...
- Etc...

But the following "enhancements" should *NEVER* (and I stress should *NEVER*) be
considered:  
- Adding more cities (overrides Zoneinfo authority)
- Primary by "common name" (confusing/conflicting/ambiguous world-wide)
- Remove the map/visual aid

Again, CLOSE/NOTABUG

One final nugget, should someone else find this in a search.  To add additional
Olson Zoneinfo paths (regions, counties, cities, etc...), the package in
question is ...
  tzdata

*NOT* redhat|system-config-time, anaconda, etc...

The GUI interface is improved since I filed this bug in FC2. It is possible
(though not easy) to find my timezone without knowing that Chicago is in it. You
may say this works as designed. Whether it is a bug is just nomenclature.

Two final comments ...

1.  RHEL3 (based on RHL9) works as *I* described

I'm running "enterprise" RHEL3 on this very system, which is based on RHL9/FC1,
2-3 "community" releases (12-18 months) prior to FC2/3 (which "enterprise" RHEL4
is based on).  I don't know if the interface has changed or not with updates,
but I don't think so.  I wouldn't be shocked if Anaconda, based on the same
Python/GTK+, didn't do it as well -- although Anaconda's run-time codebase as
built isn't always 100% sync'd with the current releases' run-time sometimes (I
have to admit that fact).

2.  The "root cause" of your "problem summary" isn't the "interface"

The "interface" -- i.e., redhat|system-config-time (probably also used by
Anaconda) -- isn't the "root cause" of your summary ...
  "timezone map contains no cities near my location"  

The "root cause" is that the Olson Zoneinfo Database (/usr/share/zoneinfo) tree,
which Red Hat packages as tzdata, does not have the cities you desire.  The
"interface" does not -- and quite properly so -- try to introduce any "new
authority" over any paths -- i.e., regions/cities/counties/etc... -- in the
Zoneinfo Database.

As such, unless you want to radically change the operation of
redhat|system-config-time and make it an "additional authority" over tzdata, it
should *CONTINUE* (and I stress *CONTINUE*) to work by referring to tzdata as
the authority.

Any further bugs on "no cities near my location" should be filed with tzdata. 
Any changes in how redhat|system-config-time uses tzdata should be "enhancements."

As such, this should be CLOSED/NOTABUG.

Have someone clone it if you wish.  I'm not a Red Hat employee and I was merely
researching Bugzilla when I saw this.  I have *0* authority in Red Hat.  I do,
however, deal with 24x7, real-time, embedded and back-end financial systems that
are used world-wide.  My current client is the #1 world-wide provider of such
solutions.

- changing version to "devel"
- adding Petr Machata (tzdata maintainer) to Cc, thought you might be interested
in this

People, I have an idea how this could be done without s-c-date trying to
override tzdata authority on the timezones/associated cities:

- establish a second list (either in tzdata or s-c-date, I don't really care)
which "links" larger cities to "their" timezone/"primary" city, i.e. the list
would contain a city name, its "primary city" and its ICBM coordinates
- s-c-date would still only configure the "primary cities", but highlight/reveal
the "secondary cities" when hovering over a timezone.

Comments?

Nils, thanks for CCing me.

For the second list idea... this would be unsupportable.  There are enough
shenanginas with researching which part of the world sticks with which twist of
which government.  That's what Olson, Eggert and others are dealing with all the
time.  Imagine we'd have to additionally check that the cities in our list map
to the cities in tzdata the way they should.  Especially when, as it is, this
mapping doesn't depend solely on world coordinates.  I wouldn't count on the
border towns keeping their TZ-alignment constant, so the list *would* have to be
updated.

I second Bryan's opinion that we shouldn't touch tzdata themselves.  I already
have these visions of freaked out bank admins who find their records an hour off.

I believe an easier idea, overall, than the second list would be to convince the
whole world to run exclusively on GMT. So much simpler!

Petr, though relucatantly ;-), I agree. Closing WONTFIX.