RE: Strange output from zdump for 2038
The zdump manual page notes the output to be expected when using the -v option: -v For each zonename on the command line, print the time at the lowest possible time value, the time one day after the lowest possible time value, the times both one second before and exactly at each detected time discontinuity, the time at one day less than the highest possible time value, and the time at the highest possible time value, Each line ends with isdst=1 if the given time is Daylight Saving Time or isdst=0 otherwise. So the two 1901 lines and the two 2038 lines are to be expected. --ado -----Original Message----- From: Dave Rolsky [mailto:autarch@urth.org] Sent: Saturday, July 19, 2003 4:34 PM To: tz@lecserver.nci.nih.gov Subject: Re: Strange output from zdump for 2038 On Sat, 19 Jul 2003, Dave Rolsky wrote:
autarch@houseabsolute:~/DateTime/modules/DateTime-TimeZone$ zdump -v Asia/Aqtau | grep 2038
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
Surely that's not right ;) I'd suggest that it's better to simply not output anything rather than output bad data. Obviously this is related to the 32-bit-ness of time_t, and is probably really a zic problem.
The same problem occurs at the other end of integer: 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 -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
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.
On Mon, 21 Jul 2003, Olson, Arthur David (NIH/NCI) wrote:
The zdump manual page notes the output to be expected when using the -v option:
-v For each zonename on the command line, print the time at the lowest possible time value, the time one day after the lowest possible time value, the times both one second before and exactly at each detected time discontinuity, the time at one day less than the highest possible time value, and the time at the highest possible time value, Each line ends with isdst=1 if the given time is Daylight Saving Time or isdst=0 otherwise.
So the two 1901 lines and the two 2038 lines are to be expected.
An explicit mention of the 32-bit int overflow problem might be in order, I think. Something along the lines of: Because most systems represent seconds since the epoch as a 32-bit int, discontinuities may be incorrectly detected when this int overflows. For a signed 32-bit int, this will occur in the years 1901 and 2038. The discontinuities reported because of this overflow do not represent actual changes in that time zone. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
participants (3)
-
Dave Rolsky -
John Cowan -
Olson, Arthur David (NIH/NCI)