Bug 103736 - /etc/localtime regeneration after modification of /etc/sysconfig/clock
Summary: /etc/localtime regeneration after modification of /etc/sysconfig/clock
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: initscripts
Version: 2.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-04 14:00 UTC by Roger Nunn
Modified: 2014-03-17 02:38 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2003-09-05 16:24:07 UTC

Attachments (Terms of Use)

Description Roger Nunn 2003-09-04 14:00:23 UTC
Description of problem:
/etc/localtime never regenerated after changes were made to /etc/sysconfig/clock

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.edit /etc/sysconfig/clock (changeing timezone for example.)

Actual results:
the date command returns the old timezone value even after reboot as it relies
on /etc/localtime which is not updated at system boot.

Expected results:
/etc/localtime is regenerated based on the new /etc/sysconfig/clock settings

Additional info:

Comment 1 Bill Nottingham 2003-09-04 17:02:28 UTC
It's regenerated when you use the included tools to modify /etc/sysconfig/clock;
if *that's* not happening, that's a bug.

Comment 2 Bastien Nocera 2003-09-05 08:07:51 UTC
redhat-config-time doesn't allow for the selection of some timezones, like GMT
and the likes.
I think that a small modification to the initscripts to regenerate
/etc/localtime on boot (or even on shutdown/reboot) would be a good thing.

Comment 3 Bill Nottingham 2003-09-05 15:09:05 UTC
Impossible to fix completely. It would need to be done before you set the time,
and you don't necessarily have a /usr filesystem to copy *from* then.

Comment 4 Bastien Nocera 2003-09-05 16:08:41 UTC
Or before you're switching the machine off, during the shutdown.

Comment 5 Bill Nottingham 2003-09-05 16:24:07 UTC
In the case of manual modification of config files, it's the sysadmin
responsibility to fix the consequences of such; I'm unwilling to start down the
slippery slope of fixing them up afterwards in an automated fashion.

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