lkml.org 
[lkml]   [1998]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Off-topic year-2000
Date
From

In article <Pine.LNX.3.95.980116034803.342A-100000@chaos.analogic.com> you wrote:
> Investigation of Y2K stuff has shown....
> With the following program:

> Linux 2.1.70 with libc-5.3.12 shows....

> 386D89D0 Sat Jan 1 00:00:00 2000
> (correct)

> Linux 2.1.70 with glibc-2.0.5 shows:

> 386D89D0 Sat Jan 1 05:00:00 2000
> (incorrect)

> SunOs 5.5.1 shows:
> 386D89D0 Sat Jan 1 00:00:00 2000
> .... Which is the same as Linux with libc-5.3.12

> The current time, set by (void)time(&tim); in the program is correct
> in all cases and does not show the 5-hour difference. The 5-hour
> difference is likely caused by our 5-hour offset from GMT, but it
> doesn't show such an offset when using the current time, only in
> the future time.

When I do the same test for my glibc setup, it works as it
should. Also, there is no difference between now and 2 years
from now, so I don't think it has anything to do with y2k.
It looks like your glibc is always runnning in GMT. Are you
sure you have the timezone files installed in the right place.
glibc needs them in /usr/share/zoneinfo/ whereas libc needed
them in /usr/lib/zoneinfo/.

> My TZ variable is set as TZ=EST and is exported. Removing it makes
> the time GMT so I know it's being checked and included in the
> calculations.

I can't understand this. Are you saying the results for glibc
are different if you remove the variable?

I have glibc-2.0.5c-10 from Red Hat.

--
Erik Corry erik@arbat.com

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.032 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site