Linux 4.18 Continues Prepping For The Year 2038

[phoronix]

Phoronix: Linux 4.18 Continues Prepping For The Year 2038

The Linux kernel has already been prepping for years for Year 2038 and that work is still ongoing with the in-development Linux 4.18 kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18-More-Y2038-Prep

[makam]

That is 20 years from now...

TFW in 20 years someone will still have a legacy 20+ year old system churning away supporting something that is critical but nobody remembers that it is critical.

[GunpowaderGuy]

makam systems dealing with future dates will be affected earlier

[eydee]

They predicted the end of the world because of the year 2k issue. It didn't happen. It's a safe bet that it won't happen in 2038 either.

[Termy]

They predicted the end of the world because of the year 2k issue. It didn't happen. It's a safe bet that it won't happen in 2038 either.

But it's still better to adress it now than to have a collective panic as it was in 99

[rtfazeberdee]

They predicted the end of the world because of the year 2k issue. It didn't happen. It's a safe bet that it won't happen in 2038 either.

well, they did spend millions on making sure it didn't. Thats the problem with "scare stories" when they don't happen, people overlook the obvious facts that other people did the work and found solutions to make sure said "scare story" didn't happen.

[makam]

well, they did spend millions on making sure it didn't. Thats the problem with "scare stories" when they don't happen, people overlook the obvious facts that other people did the work and found solutions to make sure said "scare story" didn't happen.

You can't be sure if your prevention is working until you try going without it.

[L_A_G]

well, they did spend millions on making sure it didn't. Thats the problem with "scare stories" when they don't happen, people overlook the obvious facts that other people did the work and found solutions to make sure said "scare story" didn't happen.

You do realize that's exactly what all of the overpriced consultants who did all of the "Y2K Compliance" checks would have said even if there were no problems.

Really, the whole thing just boiled down to the media wanting a huge story to report and greedy consultants all too eager to take advantage of the situation. All that really happened was some stupid things like 103-year-olds being sent kindergarten invitations and perishable food items being thrown out by mistake.

[jpg44]

Its already a problem now because some software has to use dates that far into the future. Like financial and scientific software. One solution of course is to address it in a time API that uses explicitely 64 bit integer rather than a native integer on all platforms. This can involve using an 8 byte array, or the fixed width 64 bit integers, on 32 bit platform loading the lower and upper part of the array seperately and running seperate 32 bit operations to simulate 64 bit operations . time_t is often assumed to be a native int and some code exists that puts time_t values into a native int. This has been discussed for years, one possible solution to make time_t 64 bits on 32 bit platforms, is implement a new 64 bit ABI, have a stdlib/compiler switch that causes the toolchain to cause time()/time_t use that rather than the 32 bit one, have a tool in the compiler to raise warnings if int cast is found, and also a tool to automatically rewrite code so time_t always goes into explicitely 64 bit data types.

An argument can be made for always using fixed width integers for data and saving native ints for pointers. The size of data fields is driven by the needs of the application rather than CPU register size. Some might argue that fixed width might consume more cycles on CPUs with smaller registers. But the determining factor on the correct size is the application , so you can make an argument that the correct size would not be different on different CPUs.

[wizout]

You can't be sure if your prevention is working until you try going without it.

I truly hope you never end up managing life-critical systems.