[TUHS] The 2038 bug...

[alan at alanlee.org]

64-bit migration is the ideal solution.  However there is a band-aid 
that can be applied to extend the life of 32-bit only systems.  One 
could reclaim part of the previous epoch window going forward.  That is, 
once 32-bit time_t rolls over, assume any value from -2 billion to some 
additional arbitrary positive time offset had indeed just rolled over.  
Add a whole 0x100000000 to it in a 64-bit context and evaluate (or 
evaluate against the old epoch ~+136 years).  It means a 32-bit time_t 
in this context would instead mis-represent dates from 1902 forward to 
some arbitrary threshold as modern >2038 dates.  But time_t was never 
meant to track dates outside of 'near term' relative to 'modern day' - 
eg +/- 68 years from 1970 when it was conceived.  It's reasonable to 
assume as the use of such software has moved forward in time, its time 
reference should as well.

-Alan H.

On 2020-12-31 11:12, Larry McVoy wrote:
> On Thu, Dec 31, 2020 at 09:09:33AM -0700, Adam Thornton wrote:
>> Whereas, time_t is basically internal, right?
> 
> time_t is used in syscalls, see Warner's email about i386.  It's a
> mess for 32 bit kernels.