Hi All,
This e-mail was supposed to go out yesterday, but things just kept
pilling up and I wasn't able to send it.
Since the subject was brought up.
On releases before SL3.0.8 and SL4.4, the correlation between
/etc/localtime and /usr/share/zoneinfo was not done correctly.
The problem is really with glibc.
Here's some background (this is on a SL4 system, but it's the same for
SL3, just different numbers)
$rpm -qf /etc/timezone
glibc-2.3.4-2.25.i686
$ rpm -qf /usr/share/zoneinfo/America/Chicago
tzdata-2006m-3.el4.noarch
You see that those two files are controlled by two different rpm's, the
one being glibc. (I don't know why glibc, that seems like such an odd
place to put timezone stuff, but that's a different story.)
Now, what we really want to look at is glibc-common, and more
importantly, it's post install scripts, and triggers. triggers are
scripts that get run when *other* rpm's are installed or uninstalled.
From a SL4.4 machine
$ rpm -q --scripts --triggers glibc-common
postinstall program: /usr/sbin/build-locale-archive
triggerin scriptlet (using /usr/sbin/tzdata-update) -- tzdata
From a SL4.2 machine
$ rpm -q --scripts --triggers glibc-common
postinstall program: /usr/sbin/build-locale-archive
So we see, that in the new glibc-common, they actually fixed it so that
when you update tzdata, things get updated correctly.
Was that in the glibc release notes. Yes. But, it was overlooked just
a bit.
So, what is the solution?
Everyone must update to S.L. 4.4 or S.L. 3.0.8.
No no no no
OK, so we really only saw two solutions. Write a SL_ rpm tweek, or push
out the correct glibc as an errata.
If we make a SL_ tweek, it's not going to reach everyone, in fact, it
will have to be installed by hand. And then it's going to linger on,
even after someone has updated their machine and really no longer needs
it. So, I really don't think this is a good idea.
So, we are going to be pushing out the glibc from S.L. 4.4 and S.L.
3.0.8 to their respective errata.
But we want people to be able to test this first, so I have actually put
this in the testing area, and in the 30rolling and 40rolling errata area's.
I will be sending out an e-mail soon with instructions for testing.
Thanks
Troy
Bill Feero wrote:
> 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
>>
>>
>>
>
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
|
