Bug 270 - RH 5.2 has not quite fixed timezone bug
Summary: RH 5.2 has not quite fixed timezone bug
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: timeconfig
Version: 5.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1998-12-02 20:37 UTC by Bryce Nesbitt
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1998-12-03 22:00:28 UTC

Attachments (Terms of Use)

Description Bryce Nesbitt 1998-12-02 20:37:52 UTC
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...

Comment 1 Bill Nottingham 1998-12-02 21:59:59 UTC
Are you using glibc or libc5 netscape?

Comment 2 Bryce Nesbitt 1998-12-02 23:34:59 UTC
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.


Comment 3 Bill Nottingham 1998-12-03 22:00:59 UTC
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.

Comment 4 Bryce Nesbitt 1998-12-08 23:43:59 UTC
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

Comment 5 Bill Nottingham 1998-12-14 21:29:59 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.