[tz] zdump no longer reports gmtoff

Robert Elz kre at munnari.OZ.AU
Thu Jan 31 07:20:30 UTC 2013

    Date:        Wed, 30 Jan 2013 23:26:16 -0500
    From:        Phil Pennock <tz-list+phil.pennock at spodhuis.org>
    Message-ID:  <20130131042616.GA69672 at redoubt.spodhuis.org>

  | It happens, AFAICT, because gmtime()/localtime() can't handle extreme
  | 64-bit values;

It isn't that the code cannot handle the values, but because the struct tm
data structure cannot represent the result (tm_year doesn't have enough bits).

Changing the definition of struct tm is the only way to fix this - but that's
a major change to a data structure that has existed in unix for a very very
long time (code assumes that %d printf format can print the tm_year value,
for example).

What's more, aside from zdump, there is very little practical use for times
from years outside the range of +/- 2 billion (and a few) to ever get printed
in asctime() format (or manipulated as struct tm's).   Astronomers, and others,
may occasionally want to manipulate times that far away, but they don't really
care whether we would call the day they select Tuesday or Wednesday, (etc).

Given that, the changes that struct tm will be altered, any time in the next
half billion years or so, seems very very slight to me.   Which suggests that
the right thing to do isn't to worry about localtime() sometimes returning
NULL, but rather handle it better in zdump(), and have it perhaps print
"some time so long ago we cannot represent it" (or similar, and with a similar
message for big positive times).


More information about the tz mailing list