Re: Y2038 - best way forward in Debian?
On February 14, 2020 7:45:30 PM UTC, Alan Corey <alan01346@gmail.com> wrote:
>What if we define an epoch to be 50 years and the epoch number becomes
>part of how the computer keeps track of the date. Something similar
>is done in astronomy I think, star charts always have an epoch. So
>epoch 0 was 1970, epoch 1 is 2000, epoch 2 is 2050. Then we can keep
>a time_t at 32 bits. Things like strptime() and strftime() and
>ctime() would need changing but since they were valid in epoch 0
>they'd only need to change for epoch 1 and later.
Everything that handles time would need to change. Just think of the fun of "what's one year from today?" when you cross an epic. Far easier to just make time_t 64-bit.
And file formats and protocols that currently use time_t would need to be adjusted to add a second field for an epoch. Same incompatibility concerns as 64-bit time_t.
Not to mention that the Gregorian calendar leap year cycle is 400 years long, so if you ignore the epic, you'll have no idea if it's a leap year. Which also means that you have no idea how long your 50-year epic is, since they vary, they're not all the same number of seconds, or even days.
Ultimately, you'd wind up with a presumably int-sized epoch plus an int sized time_t. That's 64 bits still...
Lastly, 64-bit time_t has been tested widely (e.g., on amd64). That's not perfect of course since 32-bit archs have smaller basic integer types, but likely a lot less work fixing the stray "int"s than adding epochs all over the place.
PS: Debian-devel is likely the wrong place to redesign C/POSIX functions.
Reply to: