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) fedora:/usr/local/netscape-4.07> The symptom of the bug is that Netscape tags email in GMT rather than the local timezone. -Bryce
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 an upgrade.
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 spot.
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.