On February 14, 2020 7:45:30 PM UTC, Alan Corey <alan01...@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.
