Bug#402776: zdump output on 64-bit architectures

[Earl Ruby <eruby@switchmanagement.com>]

I can understand why you claim that this is not a bug, however, on a
32-bit architecture I can do this:

# /usr/sbin/zdump -v -c 2008 Pacific/Guam
Pacific/Guam  Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 06:45:52 1901
ChST isdst=0 gmtoff=36000
Pacific/Guam  Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 06:45:52 1901
ChST isdst=0 gmtoff=36000
Pacific/Guam  Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 13:14:07 2038
ChST isdst=0 gmtoff=36000
Pacific/Guam  Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 13:14:07 2038
ChST isdst=0 gmtoff=36000

Now I know that for Pacific/Guam the time zone is abbreviated "ChST",
Guam does not use daylight savings time, and the UTC offset is UTC+10
(+36000 seconds).

If I type the same thing on a 64-bit architecture I get this:

# /usr/sbin/zdump -v -c 2008 Pacific/Guam
Pacific/Guam  -9223372036854775808 = NULL
Pacific/Guam  -9223372036854689408 = NULL
Pacific/Guam  9223372036854689407 = NULL
Pacific/Guam  9223372036854775807 = NULL

Which gives me no useful information at all. In fact, there is no way to
get the time zone abbreviation, whether or not the island uses DST, or
the UTC offset information out of zdump in a 64-bit environment.

This may not be a bug, but the functionality of zdump is seriously
reduced in a 64-bit environment.

Perhaps someone would be interested in patching zdump to allow a user to
specify the min/max time values to use on the command line? The system
min/max times could still be used if nothing is specified on the command
line.