zdump -v US/timezone produces "NULL" instead of MIN/MAX UTC time for 64 bit Debian/Ubuntu

[Paul Mosteika]

Other Linux 64 bit OS's have the same issue, Redhat . . . 32 bit versions have no problem as their 32 bit MIN (negative 0x80000000) and MAX (positive 0x7fffffff) values fit nicely in the time_t structure or more specifically the tm_year field of struct tm.

The problem lies in zdump.c setabsolutes() routine. Programmatically, the pkg. owner chose to print NULL for floats or very large negative and positive values, rather than to confine the MIN/MAX of the hardware architecture to that which zdump (ctime, gmtime, ascgmtime or localtime) can handle to print an actual UTC time.

       --- 64 bit Ubuntu 10.10 , 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:46 UTC 2011 x86_64 GNU/Linux ---

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

--- 64 bit Debian --- is the same, here with the timezone the MIN/MAX printable values can be seen ---
                                              --- Note 1883 -- 2499 UTC printable values ---

$ zdump -v US/Mountain
US/Mountain -9223372036854775808 = NULL
US/Mountain -9223372036854689408 = NULL
US/Mountain Sun Nov 18 18:59:59 1883 UTC = Sun Nov 18 12:00:03 1883 LMT isdst=0 gmtoff=-25196
US/Mountain Sun Nov 18 19:00:00 1883 UTC = Sun Nov 18 12:00:00 1883 MST isdst=0 gmtoff=-25200
.
.
.
US/Mountain Sun Nov 1 07:59:59 2499 UTC = Sun Nov 1 01:59:59 2499 MDT isdst=1 gmtoff=-21600
US/Mountain Sun Nov 1 08:00:00 2499 UTC = Sun Nov 1 01:00:00 2499 MST isdst=0 gmtoff=-25200
US/Mountain 9223372036854689407 = NULL
US/Mountain 9223372036854775807 = NULL

   --- 32 Bit Debian, Red-Hat ... or 64 bit with zdump patch to constrain Min/Max values to 32 bits ---
                                                 --- Note the 1901 -- 2038 MIN/MAX values ---

$ zdump -v US
US Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:45:52 1901 UTC isdst=0 gmtoff=0
US Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:45:52 1901 UTC isdst=0 gmtoff=0
US Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 UTC isdst=0 gmtoff=0
US Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 UTC isdst=0 gmtoff=0

    ---- Simple Patch/Band-aid for above, mimics 32 bit behavior ---

/glibc-2.7/debian/patches/amd64# cat zdump-NULL-fix.patch
--- ./timezone/zdump.c-Orig 2011-02-07 11:45:15.000000000 -0700
+++ ./timezone/zdump.c 2011-02-07 11:59:42.000000000 -0700
@@ -435,12 +435,12 @@ _("%s: use of -v on system with floating
    t = t1;
    t1 = 2 * t1 + 1;
   }
-
- absolute_max_time = t;
+ /* Let's confine this to 32 bits which confines the dates to 1901 and 2038 (min and max) */
+ absolute_max_time = t >>32 & 0x000000007fffffff;
   t = -t;
- absolute_min_time = t - 1;
- if (t < absolute_min_time)
- absolute_min_time = t;
+ absolute_min_time = t - 1 >>32 | 0xffffffff00000000;
+ if ( (((t - 1) >>32) | ( 0xffffffff00000000 )) < absolute_min_time)
+ absolute_min_time = t;
  } else {
   /*
   ** time_t is unsigned.

 The above mimics 32 bit behavior, but programmatically the proper values for a Min of 1883 and a Max of 2499 could be accomplished in zdump.c

One could argue that the time structures or spec. need to be updated for 64 bit operation; the underlying problem. But again I argue, that, the proper UTC values could be had by all if zdump.c were corrected, confining those values (integer or floating point), to printable UTC times. One of our customers relies on these proper UTC values, fixed locally. But, can we get upstream to take another look at this? The argument goes back to 2005 I see, refer to:

    ftp://elsie.nci.nih.gov/pub/tzarchive.gz # archive of the time zone mailing list

                       Thanks,

                       Paul

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libc6 2.12.1-0ubuntu10.2
ProcVersionSignature: Ubuntu 2.6.35-27.48-generic 2.6.35.11
Uname: Linux 2.6.35-27-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
CheckboxSubmission: 14e68c6866e3205b7d480ea63ed8cc82
CheckboxSystem: 6ce041aeed0a2c17b3343b66d157175d
Date: Fri Mar 18 15:00:57 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: eglibc

[Clint Byrum (clint-fewbar)]

This is present on natty as well:

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

libc6:
  Installed: 2.13-0ubuntu6
  Candidate: 2.13-0ubuntu7
  Version table:
     2.13-0ubuntu7 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
 *** 2.13-0ubuntu6 0
        100 /var/lib/dpkg/status

Marking as Confirmed, setting importance to Low.