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
 
BaronBS said:
TLDR: Epoch time problem was "moved" to 2038 and we need to plan for it in advance, I think.
Click to expand...
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
Click to expand...
This has been updated over 7 years ago:
github.com

arch.7: correct statement about time_t size · freebsd/freebsd-src@49ccd3f

After r320347 it is 64-bit on every architecture except i386. Sponsored by: The FreeBSD Foundation
github.com github.com

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:
github.com

Copy amd64 _types.h to x86 and merge with i386 _types.h. Replace exis… · freebsd/freebsd-src@8f77be2

…ting amd64/i386/pc98 _types.h with stubs.
github.com github.com
 
You must log in or register to reply here.
Back
Top