Date: Tue, 11 Nov 1997 13:50:33 -0800 From: Joel.Tornatore@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 problems. 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.