zdump produces bogus output on 64 bit

[Stuart Bishop]

'zdump -v' produces broken output on 64 bit architectures.

eg. Running 'zdump -v Africa/Abidjan' on i386 generates the correct output:

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

I can reproduce this building from source, so it is either a bug in the Olson timezone database or in a library.

[Stuart Bishop (stub)]

Unable to generate pytz distributions on 64 bit architectures as it uses zdump to generate the test cases.

[Matt Nordhoff (mnordhoff)]

This came up on tz's mailing list recently:

<http://thread.gmane.org/gmane.comp.time.tz/2155/focus=2156>

zdump doesn't handle it well when time_t is 64 bits and int is 32 bits.

[Stuart Bishop (stub)]

Worked around and can build tests on 64bit now.