On Tue, Feb 27, 2007 at 03:18:33PM -0500, Steven W. Orr wrote:
I'm still running Core 4 and the new DST is coming at me like a
freight
train. I got the latest src for Core 5: tzdata-2006p-1 and built it
and
installed it so I now have tzdata-2006-1 on my system.
% > rpm -q tzdata-2006p tzdata-2006p-1
The problem is:
% > date -d '27 March' Tue Mar 27 00:00:00 EST 2007
Note that it says EST instead of EDT. I have no TZ variable set.
Can someone *please* tell what I have to do to fix this?
FC4 glibc didn't have /usr/sbin/tzdata-update (it was only introduced in FC5+ and later backported to RHEL4 and RHEL3). So, after you update tzdata package, if the changes are in your default timezone, you need to return system-config-date or manually update /etc/localtime.
Jakub
Why can't you run yum update tzdata or use up2date???
BTW, you are saying FC5 machines do not need to do anything? The new DST is already in place? I have 2 Fedora releases in the field. FC3 and FC5. I also have several hundred legacy 7.2 redhat machines out there with no internet connection. Any ideas on how to fix them?
Thanks
Randy Easley wrote: [snip]
FC4 glibc didn't have /usr/sbin/tzdata-update (it was only introduced in FC5+ and later backported to RHEL4 and RHEL3). So, after you update tzdata package, if the changes are in your default timezone, you need to return system-config-date or manually update /etc/localtime.
Jakub
Why can't you run yum update tzdata or use up2date???
The tzdata-update Jakub refers to is run as part of the glibc post-install script. It doesn't matter what you use to install it (RPM, yum, up2date, whatever). Since the FC4 glibc doesn't have the tzdata-update you need to do something else to update /etc/localtime. Perhaps this page about RHEL will help:
http://kbase.redhat.com/faq/FAQ_79_9950
There is a section that discusses what to do if you don't have tzdata-update (obviously the section about updating to the RHEL glibc won't apply).