I can vouch for the realness of the problem as well. I worked for a company that made financial reporting and analysis software and we devoted a good two weeks to removing the bugs. (And another couple of months updating all our customers).

The critical bugs we had were all due to the fact that we marked our data files with 2 digit year indicators(to stay within 8 character DOS limits), which was incompatible with the logic within the program that assumed that adding and subtracting to those 2 digits will always result in 2 digits.

Of the solutions we tossed, was going to 4 digits, storing the century elsewhere, or just hardcoding logic that assumes all years 90-99 were in the 1900s, while years 00 to 89 were in the 2000s. We chose the last because it required the absolute least amount of code changes (and most importantly I finally sided with my boss who argued that most likely the software will not exist beyond 2090 in its current form, and hence make the new Y2KC bug insignificant)[No programmer can stand creating bugs you know].

Of course this was a small program that can be easily rewritten (and probably has by now). But how many more companies tasked with writing more important country (or world) infrastructure software took such shortcuts? And surely no software will last over 100 years without being totally rewritten?