[tz] question about mktime_tzname()

Robert Elz kre at munnari.OZ.AU
Thu Jan 12 10:26:40 UTC 2017

Kees.Dekker at infor.com said:
  | I don?t understand how 32-bit time_t systems can survive 2038 

There are proposals (even implemented, though I am not sure how widely)
to alter the range of 32 bit time_t, 0 is still Jan 1, 1970, but from
that positive values range from (say) 1..BFFFFFFF and C0000000..FFFFFFFF
are negative.   (The actual cutover point seems to vary).   That one would
extend the usefulness of 32 bit time_t values until 2072 (or perhaps beyond,
depending upon the switch point) and limiting the earliest value to 1936
(or whatever) isn't likely to seriously bother anyone.  If the switch
point were F0000000 (so EFFFFFFF is the biggest positive value) the range of
timestamps would be from mid 1961 to mid 2097, which would probably be OK,
and gives lots of time for everything to be converted.

Note that processing isn't the issue (the 32 bit time_t values can be moved
to 64 bit variables, represented as regular 2's complement binary numbers,
for that), but converting all the places that time_t's get stored is hard.
Certainly everything new should really be using 64 bit values by now.

NetBSD was (I believe) one of the earliest systems to switch to a 64 bit
time_t (years ago now) - yet we still have to support people with filesystems
created even longer ago, that still have only 32 bit spaces for the seconds
part of the timestamps, and which are still in use (new/updated timestamps
being created every day.)

There is also lots of old application code around, some in binary only form,
which has to keep running, and in that, time_t would have been 32 bits.

How much of that will still be a problem in another 20 years, when expiry
of a current format 32 bit time_t is imminent, I have no idea.

But just switching time_t to 64 bits doesn't solve all the problems by itself.


More information about the tz mailing list