Strange output from zdump for 2038

[Olson, Arthur David (NIH/NCI)]

> The point is, however, that the gmtoff values are rubbish, the result of
> using signed 32-bit values to model mathematical integers.

The gmtoff values being output do seem to be the difference (in seconds)
between UTC and local time. (It's true that the appearance of "GMT" is bogus
but,
as noted earlier, that seems to be a GNU challenge rather than a
timeezone-package-as distributed problem.)

				--ado

-----Original Message-----
From: John Cowan [mailto:cowan at mercury.ccil.org]
Sent: Monday, July 21, 2003 9:01 AM
To: Olson, Arthur David (NIH/NCI)
Cc: tz at lecserver.nci.nih.gov
Subject: Re: Strange output from zdump for 2038


Olson, Arthur David (NIH/NCI) scripsit:

> So the two 1901 lines and the two 2038 lines are to be expected.

The point is, however, that the gmtoff values are rubbish, the result of
using signed 32-bit values to model mathematical integers.

> > Asia/Aqtau  Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 AQTT
> isdst=0 gmtoff=14400
> > Asia/Aqtau  Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 AQTT
> isdst=0 gmtoff=14400
> Africa/Abidjan  Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:29:44 1901
GMT
> isdst=0 gmtoff=-968
> Africa/Abidjan  Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:29:44 1901
GMT
> isdst=0 gmtoff=-968

-- 
My confusion is rapidly waxing          John Cowan
For XML Schema's too taxing:            jcowan at reutershealth.com
    I'd use DTDs                        http://www.reutershealth.com
    If they had local trees --          http://www.ccil.org/~cowan
I think I best switch to RELAX NG.