11 Jan
2021
11 Jan
'21
8:01 p.m.
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(a)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.