Red Hat Bugzilla – Bug 270
RH 5.2 has not quite fixed timezone bug
Last modified: 2008-05-01 11:37:48 EDT
It turns out to be a Red Hat configuration bug; netscape is
doing the _right_ thing, by calling the POSIX tzset()
function, which is supposed to get the local timezone
however the local systems wants to store it.
The glibc implementation checks the file
/usr/lib/zoneinfo/localtime, which (I gather) is a pretty
standard location for this thing.
But Red Hat puts the zoneinfo directory in /usr/share.
Oops. The solution is to make a link from /usr/lib/zoneinfo
->/usr/share/zoneinfo. Works great for my display here.
Check the timestamp on this message to be sure. I made the
link on all the machines here, except stetson, which already
had it. One of the messages mentioned that this fix
appeared in some patch or another from Red Hat, which I
assume got applied to stetson at some point.
Amusingly, Red Hat 5.2 (which Soren installed yesterday on
pie), has the same bug (a missing /usr/lib/zoneinfo). I
suppose it's possible that newer versions of glibc look in
the /usr/share location too...
Are you using glibc or libc5 netscape?
We use both 4.07 and 4.5b1, with a random assortment of libc5 and
glibc. Here's one known to have the problem at least with RH5.1:
fedora:/usr/local/netscape-4.07> ldd netscape
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40003000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40046000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4004e000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40062000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40074000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40081000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4008c000)
libdl.so.1 => /lib/libdl.so.1 (0x40123000)
libc.so.5 => not found
libg++.so.27 => not found
libstdc++.so.27 => not found
libm.so.5 => not found
libc.so.6 => /lib/libc.so.6 (0x40126000)
/lib/ld-linux.so.1 => /lib/ld-linux.so.2 (0x00000000)
The symptom of the bug is that Netscape tags email in GMT rather than
the local timezone.
libc5 binaries will have this problem.
(incidentally, those aren't the ones we ship.)
The reason we can't really fix this is that RPM can't replace
the /usr/lib/zoneinfo directory with a symlink reliably on
Gee, then it sounds like an RPM bug. Why should RPM not have the
ability to set/fix symlinks? The rpm creator could specify the action
to take if either another symlink or directory was found the same
FYI, tzset actually checks /etc/localtime in glibc (the man
page is wrong...). /usr/share/zoneinfo/localtime is a link to this.
(It's so you can have shared zoneinfo but different localtimes
for different machines.)
As for the RPM issue, to do it right you'd have to recursively
descend into the directory, and make sure every file is owned by the
package you're upgrading, etc. (Replacing symlinks isn't a problem -
replacing a directory with a file/symlink is.) It's being looked at
for a future version of RPM, but it's messy.