On Wed, Oct 8, 2008 at 11:32 PM, Olson, Arthur David (NIH/NCI) [E] <olsona@dc37a.nci.nih.gov> wrote:

As far as I know, zdump is working on 64-bit systems. Do note that time_t structures typically contain "year" elements that are less than 64 bits wide; when this is the case, very very negative and very very positive time_t values are associated with years that can't be represented using time_t's; this is why zdump shows "NULL" for these values.

I think I see. For my use, I think I should just be ignoring the first two and last two lines of zdump -v output (I'm using it to generate all the transition points from a known good implementation to check against my implementation). I'm not sure if they contain meaningful information for other use cases. Under i386 I get this: Africa/Abidjan Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:29:44 1901 LMT isdst=0 gmtoff=-968 Africa/Abidjan Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:29:44 1901 LMT isdst=0 gmtoff=-968 Africa/Abidjan Mon Jan 1 00:16:07 1912 UTC = Sun Dec 31 23:59:59 1911 LMT isdst=0 gmtoff=-968 Africa/Abidjan Mon Jan 1 00:16:08 1912 UTC = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 Africa/Abidjan Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 GMT isdst=0 gmtoff=0 Africa/Abidjan Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 GMT isdst=0 gmtoff=0 Under 64 bit I get the following: Africa/Abidjan -9223372036854775808 = NULL Africa/Abidjan -9223372036854689408 = NULL Africa/Abidjan Mon Jan 1 00:16:07 1912 UTC = Sun Dec 31 23:59:59 1911 LMT isdst=0 Africa/Abidjan Mon Jan 1 00:16:08 1912 UTC = Mon Jan 1 00:16:08 1912 GMT isdst=0 Africa/Abidjan 9223372036854689407 = NULL Africa/Abidjan 9223372036854775807 = NULL -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/

It doesn't seem that useful, even if it is the expected output:

$ zdump -v EST EST -9223372036854775808 = NULL EST -9223372036854689408 = NULL EST 9223372036854689407 = NULL EST 9223372036854775807 = NULL

What we learn form the output is that: 1. The most-negative time_t value can't be represented by a struct tm. 2. Nor can the most-negative value plus a day. 3. Nor can the most-positive value minus a day. 4. Nor can the most positive value. 5. There are no wall clock time discontinuities between the years -500 and 2500. It would be possible to add a translation of the current time into its output, but that would mean that outputs produced at different times would be different and would complicate use of the output in regression testing. It would be possible to add a translation of the time_t value zero to the output; that wouldn't complicate regression testing but would (further) complicate the job of folks using zdump to learn about transitions. --ado

Thanks for spotting my error; it's indeed "struct tm"s that can have under-64-bit year fields. --ado -----Original Message----- From: Nicolas Alvarez [mailto:nicolas.alvarez@gmail.com] Sent: Wed 10/8/2008 5:45 PM To: tz@lecserver.nci.nih.gov Subject: RE: zdump on 64bit architectures being worked on? Olson, Arthur David (NIH/NCI) [E] wrote:

As far as I know, zdump is working on 64-bit systems. Do note that time_t structures typically contain "year" elements that are less than 64 bits wide; when this is the case, very very negative and very very positive time_t values are associated with years that can't be represented using time_t's; this is why zdump shows "NULL" for these values.

You probably mean some other structure name. time_t is just a typedef for an integer type, doesn't have "year elements" :)

Alois Treindl <alois@astro.ch> writes:

Maintainer of tzcode, please let me know.

I'm not the code maintainer, but my kneejerk reaction is that this would be a nice improvement. Some thoughts: the default way to compiler zdump.c should be to use the native localtime rather than our localtime. It should continue to be possible, for example, to compile zdump.c on Solaris and use Solaris's localtime(), which is completely independent of ours.

On Oct 8, 2008, at 2:45 PM, Nicolas Alvarez wrote:

You probably mean some other structure name. time_t is just a typedef for an integer type, doesn't have "year elements" :)

He presumably meant "struct tm", whose tm_year is an int on many platforms, even in LP64 or LLP64 mode (for example, it's an "int" on my OS X 10.5.5 Mac, meaning it's 32 bits even in LP64 mode). Sol probably won't have gone red giant by the year 2^31+1900 CE, and the Earth appears to have existed in the year abs(1900 - 2^31) BCE, so, at least in theory, this *could* be an issue. :-)