32-bit 2038 issue

Paul Eggert eggert at twinsun.com
Tue Nov 11 23:08:59 UTC 1997


   Date: Tue, 11 Nov 1997 15:25:00 -0500
   From: Tom Peterson (USG) <tomp at zk3.dec.com>

   Some ideas for addressing this problem are:

   1) Expand the date/time boundaries for time zone files to a
   specific range.

The boundaries should be expanded to an arbitrary range,
so that our descendants don't have to worry about this problem.

Also, while we're on the subject, I'd prefer a format that didn't have
any arbitrary limits.  For example, I'd like to remove the arbitrary
limit of at most 255 time zone abbreviation characters.

Personally, I'd prefer a text file, and if it were well designed, it
wouldn't take more room than the current format (it'd probably take less).
Text is more portable and easier to debug.

The current C9X draft also makes some other provisions for time zones
that I haven't had time to digest; these other provisions may also
require changes to the tz file format.  We've also been kicking around
ideas for rule timestamps, to help maintenance (e.g. for DHCP).

Perhaps it is finally really time for a tz file format redesign.
Of course we should maintain a backwards compatibility option for
people who need to use the old file format.

   2) Find some way to mimic what the zic compiler does at run-time.
   This might involve generating some kind of algorithmic data for
   each time zone which can be used to calculate future transition
   times, etc on-the-fly.  I'm not sure this is possible or practical
   given the varied complexity of time zone rules.

The code already needs to deal with arbitrary POSIX.1 strings at
run-time, so it should be practical to do this.  One possibility is to
compile rules into POSIX.1 strings in the table, and then decode this
at run-time.

   with 64-bit time_t's, the tm struct becomes the limiting factor.
   Boundary checks now become an issue for localtime()/gmtime()
   instead of mktime().  This is a problem for standards at a mininum.
   While mktime() has the (somewhat ambiguous) -1 return value for
   non-representable times, no such provision is defined for
   localtime()/gmtime().

The C Standard says that gmtime can return a null pointer, and this
certainly seems like the right thing to do if tm_year cannot represent
the year.  I believe that current practice is for localtime to return
a null pointer with an unrepresentable time (e.g. negative time_t
values on some hosts), even though the C Standard does not allow for
this.  This sounds like a bug in the C Standard, and perhaps it can be
fixed in C9X.



More information about the tz mailing list