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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
