Pondering 2038

Fact is, like Y2K, anywhere that it actually costs huge amounts of money to fix / not fix, it's been done already. Mortgage systems, futures markets, basically any financial system that deals that far ahead has to take account of these things already. And that was always my query about Y2K bringing the stock markets crashing down, etc. If so, why didn't my mortgage provider crash out 25 years ago when I took out the mortgage based on that date? Because I don't even remember a MENTION of such things back in 1975 when a 25-year mortgage was still the norm.

The problem isn't the big guns and the huge infrastructure - that will solve itself as a matter of financial incentive. It's the little things that, to be honest, nobody will really care about by that time. If the clock on your in-car PC is wrong in 2038, chances are there's a LOT more wrong with the car anyway. Like the example of the old video recorder - I came across many video recorders with the Y2K problem. Fact is, nobody was using them, certainly nobody even knew how to set the timer anyway, and even when they did need the timer, they just set the time and date to something relatively comparable (who cares if the video thinks it's 1900, so long as it records tomorrow's program?).

As such, the scaremongering over Y2k38 I can see going the same way - the big guns are already dealing with those dates (which suggests their apps don't even rely on the OS to handle dates anyway). OS's are already changing the way they deal with them. In another 25 years, 99% of the equipment we're using today will be in the bin. The rest - well, that's not such much a Y2k38 problem as why are you using 25-year-old hardware to perform any kind of vital task whatsoever, without some kind of oversight process checking it's still fit for purpose? And how worried would you be if told you had to throw it in the bin and buy yourself a new one?

Even medical devices - they have to be tested and calibrated regularly and eventually those tests will include a Y2k38 test and then they'll be condemned and someone will have to go buy a new one. And not a whole great fuss will be made over doing so ("Well, we've had those for 25 years, it's about time we had a new one anyway").

Anywhere it matters, it's fixed or should have been fixed already. Anywhere it doesn't, well, it doesn't matter.

And nobody has to wait for Linux to catch up OpenBSD or any other nonsensical suggestion - just program your app to take account of it. It's something you can do NOW and test NOW and by the time it comes around, it'll be dead code as we'll be using 64-bit or even 128-bit values, processors and OS's, anyway.

Fact is, if you were able to program properly back in 1975 (and before), you were never affected and probably never will be. The same holds true for today. The bigger problem will be things like GPS and NTP timestamp rollovers (one of which comes after Y2k38 and one two years before). But, again, if you'd programmed your systems with some ounce of common sense, it still wouldn't be a problem.