Do we have a plan for 2038?

[BaronBS]

Context:

TLDR: Epoch time problem was "moved" to 2038 and we need to plan for it in advance, I think.

 

[LibreQuest]

If they have TLS by then I'm going to KolibriOS

 

[Maturin]

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

 

[sko]

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:

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

The last architecture to move to 64bit time_t was powerpc in june 2017 by the commit mentioned in the above git blame (r320347):

svn commit: r320347 - in head: . share/man/man7 sys/compat/freebsd32 sys/net sys/powerpc/include sys/sys

(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:

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

 

[fmc000]

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.

 

[Jim L.]

Is it naive to think we could set our clocks ahead and see what happens? Makes me wonder if anyone operates a "dummy" or sandbox NTP service that can accept requests:

* just for sessions involving my IP number, set UTC to <this time> (or perhaps tell the NTP server to offset time references to my IP by +/- N seconds)
* let time advance normally, and continue reporting the updated sandbox time when my IP requests a time check
* OTOH, might be easier to hack one's own NTP client and put the offset there (OTOOH, maybe I should just read the man page)

Then sit back and watch the fun....

 

[USerID]

Life won't stop with the 2038 problem. Without crypto, AI won't stop either. The rest is solvable. In 13 years, a lot of things won't exist.
It's not that bad.

Most computers and smartphones made recently are 64-bit and can hold numbers of 9,223,372,036,854,775,807. That is, they will count down to 292,277,026,596. So most of them (except for the really old ones) won't be affected.

As for ATMs, medical and military equipment, etc., by 2038, it is quite possible that most (if not all) 32-bit devices will not be used. They will be replaced by more modern systems that do not need to be fixed. The main headache may be equipment upgrades. But engineers still have 13 years to deal with it.