Bug 123101 - ZONE is not used for anything
ZONE is not used for anything
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: system-config-date (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-12 10:43 EDT by Kaj J. Niemi
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-07 07:27:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
script to set system timezone based on ZONE variable in /etc/sysconfig/clock (10.18 KB, text/plain)
2004-12-11 22:25 EST, James Valente
no flags Details

  None (edit)
Description Kaj J. Niemi 2004-05-12 10:43:01 EDT
Description of problem:
It looks like ZONE set in /etc/sysconfig/clock is not really used by
any init scripts. This leads down a fun trail of chasing a problem
which shouldn't really exist. It turns out that the authorative file
for the system time zone is actually /etc/localtime. Manual
replacement is required in case the time zone changes on a particular
system. It would be nicer if the value from ZONE was used to copy the
timezone file to /etc when starting up.

How reproducible:
Always

Steps to Reproduce:
1. Install system in America/New_York
2. reboot
3. change /etc/sysconfig/clock to Europe/Amsterdam
4. reboot
5. date
  
Actual results:
Wed May 12 10:40:04 EDT 2004

Expected results:
Wed May 12 16:40:19 CEST 2004

Additional info:
Comment 1 Bill Nottingham 2004-05-21 17:00:28 EDT
ZONE is written by the config tools as a marker of their last state,
actually.
Comment 2 Kaj J. Niemi 2004-06-01 05:59:50 EDT
Hmmh, I was more thinking of unattended installations. For example if
I kickstart about 20-100 systems at one time and then need to change
the system tz on each and everyone of them by copying to
/etc/localtime by hand it gets a bit tedious. ;-)

Would you consider including a simple patch to initscripts which
checks if the string defined in ZONE is a valid file in the
/usr/share/timezone/ directory and copies it to /etc/localtime?

I guess there might be a chicken and a egg problem since the localtime
is probably set before /usr is being mounted..?
Comment 3 Bill Nottingham 2004-06-01 12:15:16 EDT
Exactly; that's why it's a copy and not a symlink in the first place. :/
Comment 4 James Valente 2004-12-11 22:25:33 EST
Created attachment 108393 [details]
script to set system timezone based on ZONE variable in /etc/sysconfig/clock

I noticed this same problem in Fedora Core 1.  Some of the sysadmins at my
company were updating the ZONE variable in the clock file, thinking this would
set the system's timezone upon reboot, but it was not.	A search throughout the
init scripts confirmed this.  To resolve it, I wrote a new script that can be
called automatically at system startup or manually at anytime the superuser
wishes.

The script tries to make appropriate guesses as to what the system's correct
timezone should be, based on either the ZONE variable in /etc/sysconfig/clock
or the /etc/localtime file.  If the ZONE variable is valid, it prefers that. 
If ZONE is invalid or not set, then the script uses /etc/localtime and updates
the ZONE variable in the clock file.  If localtime is a symlink to a valid zone
file, then use that time zone.	If locatime is not a symlink, then the script
uses MD5 hash to find the matching zone file under /usr/share/zoneinfo. 
Finally, the script optionally emails errors, warnings, information, and debug
messages to an email address specified.

The approach I take in my script is to symlink /etc/localtime to the
appropriate zone file under /usr/share/zoneinfo.  That may or may not be
desirable behavior, but it works for me.  If not the desired behavior, then the
line "ln -s $ZONEFILE $LOCALTIME" can be rewritten as "cp -f $ZONEFILE
$LOCALTIME"
Comment 5 Bill Nottingham 2005-09-30 17:21:01 EDT
Moving to s-c-date; it's probably best for it to comment when it writes the file
that that is not the authoritative setting.
Comment 6 Nils Philippsen 2005-10-07 07:27:48 EDT
Fixed in system-config-date-1.7.99.2.

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