[TUHS] The 2038 bug...

[Stuart Remphrey]

> 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.

That seems a reasonable 2038 bandaid: analogous to Y2K reinterpreting
2-digit decimal dates as a different/higher year range than 1900-1990;
similar in effect to making 32-bit time_t unsigned.


On Mon, 11 Jan 2021, 15:28 , <alan at alanlee.org> wrote:

>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210111/64a4e308/attachment.htm>