Do we have a plan for 2038?

Of course.
As always, and everywhere else:
Do absolutely nothing about it. Relax! No problem! It's still so much time.
Especially ignore any reasonable solution that may solve the problem once and for all, particulary if it needs action before 2037.
Then Q4 2037 come. Sudden, unexpected, and unforeseen.
Panic, hysteria, mass media run over with messages of apocalypse, blame others, especially those unix cavemen for we all depend on servers still running that stone age crap instead of a modern Windows like every other reasonable person.
Qickly, and dirty patch some tinkerware on the hoof to just postpone the problem to 2076.
"There, problem solved."
But...
"PROBLEM SOLVED!"

There's a Hole in My Bucket
 
TLDR: Epoch time problem was "moved" to 2038 and we need to plan for it in advance, I think.
Yeah, sure, apocalypse is upon us... I don't know how often this FUD will reappear, but it has already been dealt with in pretty much all major OS.)


From arch(7):
time_t is 8 bytes on all supported architectures except i386
This has been updated over 7 years ago:

The last architecture to move to 64bit time_t was powerpc in june 2017 by the commit mentioned in the above git blame (r320347):
(couldn't find that commit via the very limited/crippled search capabilities (i.e. non-existent for commits) on github...)

x86 changed to int64 for time_t 14 years ago:
 
Yeah, sure, apocalypse is upon us... I don't know how often this FUD will reappear, but it has already been dealt with in pretty much all major OS.)
Well, backup software can be a major issue. For example, if your backup software is not Y2038 compatible and you want to assign a 15-year retention to some of your backups, you simply can't. Embedded devices can be a major problem also.

In short, don't focus only on OSes, the real problem will be in apps.
 
Back
Top