5 ms·
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 coul
by luso_brazilian 11y ago
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.
- BinaryIdiot 11y ago> 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.
- perlgeek 11y agoThe obvious fix is to use a 64bit integer to hold timestamps.
- luso_brazilian 11y agoThat'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?
- pavel_lishin 11y agoYou'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?
- OliverJones 11y agoFWIW, 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.