Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 270 - RH 5.2 has not quite fixed timezone bug
RH 5.2 has not quite fixed timezone bug
Product: Red Hat Linux
Classification: Retired
Component: timeconfig (Show other bugs)
i386 Linux
low Severity low
: ---
: ---
Assigned To: David Lawrence
Depends On:
  Show dependency treegraph
Reported: 1998-12-02 15:37 EST by Bryce Nesbitt
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1998-12-03 17:00:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bryce Nesbitt 1998-12-02 15:37:52 EST
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 16:59:59 EST
Are you using glibc or libc5 netscape?
Comment 2 Bryce Nesbitt 1998-12-02 18:34:59 EST
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 17:00:59 EST
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 18:43:59 EST
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 16:29:59 EST
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.