You're saying "imagine" a lot there.

Were there concrete examples of critical software that actually would've failed? At the time I remember there was one consultant that was on the news constantly saying everything from elevators to microwaves would fail on Y2K. Of course this was creating a lot of business for his company.

When you think about it storing a date with 6 bytes would take more space than using Unix time which would give both time and date in four bytes. Y2K38 is the real problem. Y2K was a problem with software written by poor devs that were trying to save disk space by actually using more disk space than needed.

And sure a lot of of software needed to be tested to be sure someone didn't do something stupid. But a lot of it was indeed an exaggeration. You have to reset the time on your microwave after a power outage but not the date, common sense tells you your microwave doesn't care about the year. And when a reporter actually followed up with the elevator companies, it was the same deal. Most software simply doesn't just fail when it's run in an unexpected year.

If someone wrote a time critical safety mechanism for a nuclear reactor that involved parsing a janky homebrew time format from a string then there's some serious problems in that software way beyond Y2K.

The instances of the Y2K bug I saw in the wild, the software still worked, it just displayed the date wrong.

Y2K38 is the real scary problem because people that don't understand binary numbers don't understand it at all. And even a lot of people in the technology field think it's not a problem because "computers are 64 bit now." Don't matter how many bits the processor has, it's only the size that's compiled and stored that counts. And unlike some janky parsed string format, unix time is a format I could see systems at power plants actually using.