in reply to Re^5: The Y2K 2038 problem
in thread The Y2K 2038 problem

Yes, I'm ignoring all the social side effects of the hype, which did create a mess. The alarm was meant for the business decision makers, not the general populace to take shelter, but a lot of the latter happened. I stand by my point that a lot of bad things may have happened without the hype, though, especially related to billing systems coded in COBOL, which was fairly common. Even a lot of newer DOS software for console had problems just because of the console/terminal mentality of squeezing information onto the 80 available columns of screen.

I also agree that 2038 won't likely have problems, because the problems have been solved so far in advance. I can't claim to be in the clear myself, though, because we have an (fairly important) app we wrote for a customer about 15 years ago using 32-bit MySQL 5.0 and they decided it was good enough to not budget any time to improve it since then. They pay us to keep the server alive and make backups, but not to upgrade anything. If we're both still in business 12 years from now, we'll need to have a talk with them about finally upgrading that. A 2038 scare among management might help produce budget for that.

Actually, I just looked it up, and even the latest MySQL 8 still limits TIMESTAMP columns to 32-bit. So anyone who doesn't realize that could still be creating new app schemas with a 2038 bomb waiting to go off, even for a modern 64-bit software stack.