A much more insidious problem with the Y2K bug was the leap year calculation. As you point out, the 20-digit-year thing was relatively easy to fix.
I still love the fact that if you only implemented the first rule or had the knowledge to implement all 3 rules, it would totally work, but if you implemented 2 of the 3 rules you were wrong.
It taught me a great lesson about results not proving correctness as how you got there could bite you later.
I don't get why people don't know all three rules. In elementary school when the calendar is taught, the complete rules of the leap year were simply taught by the teacher. We even joked about people born on the 29th of February. Why wasn't this taught everywhere?
Heh, this sentence seems particularly relevant to this whole discussion...
> This method works fine for the year 2000 (because it is a leap year), and will not become a problem until 2100, when older legacy programs will likely have long since been replaced.
Wouldn't it be this?
date="200$year"
It's been a very long time since I've worked with dBASE/FoxPro, but from what I remember it stores data in a fixed-width format. So for a column to store an integer, it will zero pad the front of it to fit the width of the column.
This is what I remember a lot of too. While they are little hacks which are imperfect, they bought companies enough time to resolve the issue more thoroughly.
and it was pretty embarrassing when I forgot to update this same thing in 2010
Man, I've just remember that I had to fix this kind of bug in 2010 and I am sure I just bumped the number to 20. I guess somebody had to be fixing it lately, I just hope they didn't just replace 2 with 3.
At the time I was managing a dBase / FoxPro medical software package...we were a small staff who had to come up with Y2K mitigation on our own.
Our problem is we only had source code for "our" part of the chain...other data was being fed into the system from external systems where we had no vendor support.
Thus our only conceivable plan was to do the old:
It worked in 99.9% of the cases which was enough for us to limp thru and just fix the bad cases by hand as they happened. Eventually we migrated off the whole stack over the next few years so stopped being a problem. I'm sure many mitigation strategies did the same....