If you want to get a glimpse of what was the Y2K Bug craze in 1999 Ullman’s chapter on it is a must.
Millenniums may ask: “What was the Y2K bug?” Well, as one who was actively working in IT at the time, it basically was the number of seriously heavyweight IT-reliant- and IT-provider-based organizations running crapped out, moth-eaten, disaster-ready systems for critical public service and infrastructure functions, systems that were originally developed for Noah's GPSing around Ararat, beggars belief. The problem with the earlier Y2K and other system's potential 1970s-based clock issue and its siblings was and is their potential for cascading. The Y2K bug did, indeed, bite a lot of systems, but it did not go critical and ignite a runaway reaction. However, before the event absolutely no-one on the planet knew for sure whether it would or not.
The real problem was in the corporate/government sphere where old systems running in-house code needed to be fixed and/or replaced, although those systems could be running on quite small hardware platforms, and the risks were real that something serious might happen, and people needed to be informed so that they could carry out the necessary checks (even if that meant doing nothing). It's very true that the vast majority of consumer (and small business) hardware/software applications were sorted by the natural replacement cycle and by the fact that widespread adoption of computers at that scale was comparatively recent (by which I mean the late eighties and nineties). The challenge, as anyone who has done any serious integration testing on enterprise scale applications knows, is testing all the different scenarios; the risk of a cascading failure is ever present.
Simulating 'what-if' scenarios against a future time was particularly hard, since we had to advance the system clocks of many applications simultaneously (or simulate the impact of that). Where finance postings were involved (as is typically the case with billing and logistics systems) that becomes exceptionally difficult to plan and organise. In nearly 20 years of working in one the largest organisations in Portugal, I had never seen such testing done on such a wide scale. At the time, I certainly didn't condone 'mass scaremongering' and I was not gleeful that the world mostly acted professionally to fix the Y2K problem. I'm happy that the risks were assessed and a conservative precautionary principle was followed. If we couldn't realistically have tested all the possible failure modes of a future time flipping things into an unstable state it was safer to find and fix as many of the bugs as possible well in advance. I think it's sad that unscrupulous businesses used it as an opportunity to pressurise people to upgrade and replace things that might safely have been left alone, rather than educating them to do more research and maybe decide for themselves that they were, in fact, ok. The sad fact is that for many people IT fulfills Arthur C. Clarke's maxim: "any sufficiently advanced technology is indistinguisable from magic", and they will always be prone to being conned.
Will we have another Y2K-craze in 2038? I doubt I will last until 2038 (or the advent of its analogous problem in other systems, probably around the same time) but, if I do, I really hope this time sees a cascading reaction; it will indeed be a pleasure to go out, to adapt Bob Monkhouse's anecdote, listening peacefully to the screams of a multitude of hitherto complacent and ill-informed dweebs as their teetering systems crash and burn around them. I'll rouse myself briefly and LOL: "Ha ha," I'll go. "Ha ha ha." I'll probably be dead when all the planes fall out of the sky this time, so no worries…
How can we motivate corporate businesses to address the 2038 issue? Simple. With threats. Ultimately it is all fixable; I wouldn't panic right now, though it is time to start worrying about it. And anyone coding time into 32 bit numbers right now deserves to be forced to use Windows 3.1 for a month until they promise never to do it again…
NB: A personal note. The Germans calmly assessed the situation and ported non Y2K compliant IBM COBOL code into Y2K compliant SAP ABAP code, and launched one of the largest software companies on Earth. Implementing SAP R/3 to replace old IBM ERP solutions was one of the main ways that companies world-wide avoided the Y2K problem. I was head of an IT SAP Systems Administration team at the time, and the only think I had to worry about was to make sure all the programs developed by humans were Y2K-Compliant, and that was still a big worry I can tell you. My team spent New Year’s Eve at the office to make sure everything went according to plan while other teams were in the trenches... I remember my team drinking and eating on New Year's Eve...Wondrous times that won't come back.