Red Hat Bugzilla – Bug 201969
redhat-config-date and timeconfig break customized timezone settings
Last modified: 2008-05-01 11:38:06 EDT
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Customize timezone setting by copying an Olsen zone file that is not listed
in the redhat-config-date timezone menus from /usr/share/zoneinfo to
/etc/localtime. Edit /etc/sysconfig/clock to set ZONE appropriately. Typically
this is done to put systems in the UTC zone, a perfectly reasonable requirement.
2. Run redhat-config-date or timeconfig.
system-config-date decides you must want to use the timezone for New York (not
even US/Eastern, but America/New_York).
system-config-date should not assume that you want to use a geographical time
zone, and if it doesn't recognize the zone you're in from /etc/localtime, it
should leave it alone.
The Red Hat tz config tools have a limited number of available zones, all
geographically based. It is essential with many systems (e.g. global observing
systems) to be able to set a logical zone, often UTC, on all participating
hosts. Unfortunately, Red Hat updates interfere with this process. As documented
in bug 199792, glibc updates sometimes overwrite /etc/localtime with the zone
file specified in /etc/sysconfig/clock. Meanwhile, the instructions for today's
tzdata update direct admins to run "system-config-date" (which is of course
wrong). So there is effectively no way to put a system in a zone outside the
limited geographic zones available in redhat-config-date/timeconfig and keep it
Once upon a time, timeconfig provided a complete list of zones. At some point
(RHEL 3?) the list was shortened to its current limited state. This change
should be undone.
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.
It's (In reply to comment #1)
> This bug is filed against RHEL 3, which is in maintenance phase.
> During the maintenance phase, only security errata and select mission
> critical bug fixes will be released for enterprise products. Since
> this bug does not meet that criteria, it is now being closed.
That's clever. Just ignore bugs until you're in maintenance phase, then close them.
Same problem exists with RHEL 4, by the way. Sanity was finally restored with