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@mercury.ccil.org] Sent: Monday, July 21, 2003 9:01 AM To: Olson, Arthur David (NIH/NCI) Cc: tz@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@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.