Bug 270

Summary:	RH 5.2 has not quite fixed timezone bug
Product:	[Retired] Red Hat Linux	Reporter:	Bryce Nesbitt <bryce>
Component:	timeconfig	Assignee:	David Lawrence <dkl>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	5.2
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	1998-12-03 22:00:28 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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)
fedora:/usr/local/netscape-4.07>


The symptom of the bug is that Netscape tags email in GMT rather than
the local timezone.

                        -Bryce

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
spot.

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.