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