A number of you will have noticed already that the 64-bit time_t transition is now in progress in Debian experimental.
The goal of this transition is to ensure that 32-bit architectures in trixie (whether they are currently release architectures, or out of archive, etc) will be capable of handling current and future timestamps referring to times beyond 2038.
↫ Steve Langasek on debian-devel-announce
A crucial effort.
The vast bulk of the human planet is completely ignorant about how things like this affect them, but as we move ever more closer to an AI powered internet of everything, efforts like this are crucial as @Thom mentions. I suppose in maintaining old hardware I’ve become conditioned to look for problems like this, but I find it bizarre that in many cases trained technicians and users of industrial or research equipment can be completely ignorant of time and date issues that can have real world effects. They look at the data, but they don’t look at the timestamp, or they dismiss the timestamp being wrong as irrelevant.
Heh, as Vernor Vinge wrote in A Deepness in the Sky (https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky).
[quote]Take the Traders’ method of timekeeping. The frame corrections were incredibly complex – and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely … the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems.[/quote]
Thousands of years from now, if humanity is still around, we’ll probably have Unix time buried somewhere at the bottom of the stack.
Ugh, how do I do quotes properly here? Clearly not BBCODE. Nor can I edit, even for a tiny amount of time after initially posting.
Block quotes can be done with <blockquote> and </blockquote>
Or, if that doesn’t show up properly, use the blockquote tag between angle brackets
Drizzt321,
Possibly. In principal most applications could still work relative to another newer date, but the date printing/parsing algorithm would need to be updated for this new date range.
This is problem with a legacy 32bit API on linux, but otherwise 32bit hardware can handle 64bit times just fine.
https://stackoverflow.com/questions/16521066/is-u-int64-t-available-on-32-bit-machine
It seems like a bad idea to define time_t in terms of an architecture dependent size. But to be fair, a lot of our technology was devolved by people who never expected their work to last this long.