32-bit 2038 issue

Paul Eggert eggert at twinsun.com
Tue Nov 11 23:36:37 UTC 1997

   Date: Tue, 11 Nov 1997 13:50:33 -0800
   From: Joel.Tornatore at Eng.Sun.COM (Joel Tornatore)

   changing time_t to an unsigned int would give another 68 years

But that would break backward compatibility with many applications.
Few vendors have gone to an unsigned time_t (in fact, I don't know of
any offhand) and there are good reasons for this.

I can represent my date of birth as a signed time_t, but not as an
unsigned time_t.  Many apps depend on storing dates of birth and the
like.  (I know POSIX.1 doesn't guarantee that time_t is signed, but
we're talking common practice here.)

I don't think that changing time_t to a 64-bit quantity will hurt
performance much.  Few apps have arrays of a million time_t values.
The biggest hassle of going to 64-bit time_t will be compatibility

I've heard that Solaris 2.7 will support LP64.  Clearly Sun will have
many compatibility problems in growing `long' from 32 to 64 bits.  I
expect that the most natural thing for Sun to do is to make time_t 64
bits in LP64 mode, as historically time_t was an alias for `long' and
I still run into software that assumes this.  This may cause some
compatibility gotchas, but to some extent they're inevitable and at
any rate they'll be in the noise compared to the overall hassle of
going from ILP32 to LP64.

More information about the tz mailing list