No mention to Y2K and mankind can thank the millions of man/hours employed (and regally paid) to stamp out the majority of the occurrences of that bug.
It could really be a game changer if it didn't get fixed and I don't really know what expect in the wake of Y2K38 because it's about there, lurking in waiting.
> I don't really know what expect in the wake of Y2K38 because it's about there, lurking in waiting.
I've been wondering the same. The Y2K bug was easy for many places to fix. Granted I wasn't a profressional developer at that time but I've looked at historical fixes at the companies I have worked at and all of their solutions were pretty easy (change application code to use 4 numbers instead of 2, run SQL update script to update existing data, done). But the 2038 bug? That one isn't near as obvious to fix in my opinion.
That's the fix, of course, but what about all the embedded software that will last enough to cross that barrier but that won't be upgraded from its 32bits timestamps?
You'd have to find it, too. How many companies have manufactured devices with embedded software that have gone out of business, devices for which no manuals exist anymore, etc?
FWIW, the year 2027 has the same weekdays as 2038. If the worst comes to the worst, setting the clocks back 11 years on unremediated systems has a chance of allowing them to keep working.
It could really be a game changer if it didn't get fixed and I don't really know what expect in the wake of Y2K38 because it's about there, lurking in waiting.