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

AFAIK, the Year 2000 problem was nowhere near as catastrophic as many had predicted.

It was not catastrophic because of the hype. For example, the small factory I worked at as an intern had a "Y2K Intern" role. As in, they approached the local university and specifically hired co-op students over the course of about 1.5 years to run all their factory software across the Y2K boundary. This would not have happened if the Y2K scare was not looming large over the managers.

In that sense, the scare over Y2K was a success story. The engineers all knew that shit was going to hit the fan, and collectively alarmed the managers of the world to do something about it.

Replies are listed 'Best First'.
Re^5: The Y2K 2038 problem
by afoken (Chancellor) on Mar 20, 2024 at 23:59 UTC
    It was not catastrophic because of the hype.

    Yes, but ... - As usual, there was a lot of nonsense, and people earned a lot of money with nonsense.

    Is your mechanic 0-60 min cooking timer Y2K compatible? How about your electronic one? Yes, it's only job is to count down from at most 60:00 to 0:00, and it does so whatever date is. It has no idea of the date. But still, people sold them with a "Y2K compatible" badge.

    Same with simple clocks counting only seconds, minutes, and hours, but no days, months, or years.

    Same with keyboards, mice, printers, floppy drives, floppies.

    Many people offered ther services as "Y2K consultants". Some of them couldn't tell the difference between a mechanical type writer and a PC, but that did not prevent them from consulting bullsh*t and demanding money for worthless Y2K stickers and certificates.

    I still remember checking servers and clients for their behaviour around the roll-over from 1999-12-31 23:59:59 to 2000-01-01 00:00:00. On recent hard- and software of that time, the roll-over was no problem at all. I even was contacted by the user of my first sold software, asking if it was Y2k compatible. (Yes, it was, years before Y2K. I dislike the usual year mod 100 notation, so all of my software always uses the full year.)

    Some clever people have build replacement RTCs that could be plugged into all PCs with an ISA slot (almost all at that time). That RTCs did properly roll over from 1999 to 2000, and came with their own little BIOS to handle the roll-over. They sold pretty well, even if almost no PC needed them. Generic BIOSes and RTCs could handle the roll-over without any support.

    My guess for the Y2K38 problem?

    Technically, I don't expect big problems. It affects only system using Unix time stamps , and only those where time_t is a signed 32-bit integer. 64 bit systems use a 64-bit signed integer for time_t, and more and more systems are 64 bit. And their share will grow even more until 2038. So, it is a legacy systems problem. Linux changed time_t to 64 bit even on 32-bit systems years ago, so no problem there. I think the BSDs already did the same. So, 2038 will be a problem for only for systems that are considered legacy NOW. Systems installed today will be "old" or "legacy" in 2038, and they won't have a Y2K38 problem. (Of couse, some applications might still use a 32 bit timestamp defined like time_t, but not defined as time_t, even on 64 bit systems, and they WILL fail. But the OS itself shouldn't have a problem.)

    In the public, it depends. As explained, using 64 bit systems should mostly solve the problem. It may gain some "computers will kill us if we don't fix the time_t problem" momentum, but I doubt journalists will fully understand the problem. So we will probably face a some nonsense, but because Y2K went so smooth, I hope that nobody (except for some IT experts) really will or needs to care about 2038.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]
      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.

[reply]

In Section Seekers of Perl Wisdom