Strange output from zdump for 2038

[Olson, Arthur David (NIH/NCI)]

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 at urth.org]
Sent: Saturday, July 19, 2003 4:34 PM
To: tz at lecserver.nci.nih.gov
Subject: Re: Strange output from zdump for 2038


On Sat, 19 Jul 2003, Dave Rolsky wrote:

> autarch at 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
=======================*/