Linux 4.18 Continues Prepping For The Year 2038

[torsionbar28]

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.

^ This is true for much of what's considered "news" these days.... Who cares about facts, we have a panel of experts here to weight in with their opinions! Stay tuned, so we can influence your opinion!

[makam]

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

I do hope so too as having so much responsibility would be dancing around my stress threshold.

However i think you misunderstood what I was trying to say. I never meant to say that you should remove preventions to test it out.

I was referring to how when things are working correctly nobody gets thanked, but when things break everyone blames you. Same when the year 2038 happens, few people will thank engineers and think about the many hours that went into fixing the problem, most will just say 'Oh those pesky engineers have overblown that problem, yet barely anything happened'.

[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.

[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.

[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.

[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.

[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.

[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

[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.

[GunpowaderGuy]

makam systems dealing with future dates will be affected earlier