Red Hat Bugzilla – Bug 469828
several small issues regarding GMT timezone selection in anaconda
Last modified: 2015-05-04 21:34:22 EDT
Description of problem:
Here are some issues issues regarding the GMT timezone selection:
1) The Etc/GMT* timezones should probably renamed to Etc/UTC* for consistency (e.g. there is Etc/UTC and the checkbox for the hardware clock also uses UTC instead of GMT)
2) Maybe there should be also a Etc/UTC+13 timezone, because this is the timezone in New Zealand during Daylight savings time (see bug #6175)
3) The Etc/ timezones are not sorted numerically, e.g. GMT+10 follows GMT+1 instead of GMT+9
Version-Release number of selected component (if applicable):
188.8.131.52 from Snap3 i386 DVD
The last is anaconda-specific, though the timezones are really text strings where a few of them just happen to have numbers at the end, so sorting them numerically isn't all that straightforward. The other problems are timezone data specific.
1) We can't just rename zone, if anything we would add Etc/UTC* and provide Etc/GMT* zones as backlinks. However there's no reason to do that either, just use POSIX TZ notation (e.g. TZ="UTC-4") to get the right zone:
$ for i in UTC-4 Etc/GMT-4; do env TZ=$i date; done
Tue Nov 4 22:43:08 UTC 2008
Tue Nov 4 22:43:08 GMT-4 2008
2) Etc/GMT+13 is not necessary, New Zealand (and its neighbourhood) lies in Etc/GMT-13, which is already present. If you think it should in fact be Etc/GMT+13 then you are right, but for POSIX compatibility reasons (see the UTC notation above), zoneinfo database has the sign switched. So:
$ for i in Pacific/Auckland Etc/GMT-13; do env TZ=$i date; done
Wed Nov 5 07:50:15 NZDT 2008
Wed Nov 5 07:50:15 GMT-13 2008
I'd mark this NOTABUG as far as tzdata is concerned.
Oh, I see it's assigned to me, so I'll simply NOTABUG it myself.