I've just had to go through this. I thought that installing the tzdata update was
enough. But I also had to run timeconfig on some systems. I discovered that some
of my systems had /etc/localtime symlink'd to a zoneinfo file - those systems
did not need timeconfig. Other systems had /etc/localtime as a copy of the
zone file; on those I needed to run timeconfig.

I'm going to visit each system and make /etc/localtime a symlink.


FYI - the files in /usr/share/zoneinfo are hard linked to similar zone files, 
i.e. US/Eastern & America/New_York are the same file.

Bill Feero

On Thursday 01 March 2007 8:09 pm, Michael Hannon wrote:
> Greetings.  This could be sub-titled "When is Los Angeles != Tijuana?". 
>   I suppose this a mainly a west-coast issue, but in the past I have 
> often chosen "America/Tijuana" as our time zone when installing SL or 
> the upstream distribution.  It just seems a little easier to point the 
> arrow on the map to Tijuana, and both places have been listed as 
> US/Pacific, so how could it matter?
> 
> Now it seems that it DOES matter.  We've just started to look into the 
> ramifications of the looming implementation of the changes in the rules 
> for Daylight Savings Time (DST).  It appears that there has been a 
> tzdata update for almost a year that supposedly deals with the new rules.
> 
> Evidently, one can check that the update has been installed by using the 
> "zdump" command (see the appended).  On the first system we checked, the 
>   time zone was set to "America/Tijuana", and the zdump check showed the 
> OLD DST rules were in effect.
> 
> We re-ran system-config-date and selected, as the only change, the time 
> zone "America/Los_Angeles".  A subsequent run of zdump showed that the 
> NEW DST rules were now being used for that zone.
> 
> Thus, I believe that the story has a happy ending, at least for this 
> system.  But I would like not to have to run an interactive utility on 
> every system for which we have to make this change.  It would be easy 
> enough (sed or equivalent) to make an automated edit of 
> /etc/sysconfig/clock.
> 
> On the other hand, it appears that the time-zone information must also 
> be reflected in the data file /etc/localtime.
> 
> My first question is: is the time-zone information stored any place 
> besides the two files /etc/sysconfig/clock and /etc/localtime?
> 
> And regarding /etc/localtime: I don't know the format of the file, but 
> in all of the systems in our classroom the file /etc/localtime has 
> exactly the same size (1017 bytes) and has exactly the same "strings" 
> output.
> 
> My second question: is it safe to assume that any two systems at the 
> same revision of SL and in the same time zone have exactly the same 
> contents in /etc/localtime?
> 
> Thanks.
> 
> 					- Mike
> 
> 
> [root@xxxxxx sysconfig]# cat clock
> ZONE="America/Tijuana"
> UTC=true
> ARC=false
> 
> [root@xxxxxx sysconfig]# zdump -v "America/Tijuana" | grep 2007
> America/Tijuana  Sun Apr  1 09:59:59 2007 UTC = Sun Apr  1 01:59:59 2007 
> PST isdst=0 gmtoff=-28800
> America/Tijuana  Sun Apr  1 10:00:00 2007 UTC = Sun Apr  1 03:00:00 2007 
> PDT isdst=1 gmtoff=-25200
> America/Tijuana  Sun Oct 28 08:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 
> PDT isdst=1 gmtoff=-25200
> America/Tijuana  Sun Oct 28 09:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 
> PST isdst=0 gmtoff=-28800
> 
> [root@xxxxxx sysconfig]# system-config-date
>      (change only the time zone: America/Los_Angeles)
> 
> [root@xxxxxx sysconfig]# cat clock
> ZONE="America/Los_Angeles"
> UTC=true
> ARC=false
> 
> [root@xxxxxx sysconfig]# zdump -v "America/Los_Angeles" | grep 2007
> America/Los_Angeles  Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 
> 2007 PST isdst=0 gmtoff=-28800
> America/Los_Angeles  Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 
> 2007 PDT isdst=1 gmtoff=-25200
> America/Los_Angeles  Sun Nov  4 08:59:59 2007 UTC = Sun Nov  4 01:59:59 
> 2007 PDT isdst=1 gmtoff=-25200
> America/Los_Angeles  Sun Nov  4 09:00:00 2007 UTC = Sun Nov  4 01:00:00 
> 2007 PST isdst=0 gmtoff=-28800
> 
> 
> 

-- 
Bill Feero
Logical Solutions, Inc.