The Y2K bug gets in its last lick.
January 1, 2001 4:30 PM Subscribe
The Y2K bug gets in its last lick. We all thought we were safely past that a year ago, didn't we?
My friend's cell phone read "12/30/2000" all day yesterday. It out-and-out refused to acknowledge the existence of December 31, though come midnight it read "01/01/2001", as would be expected.
Not exactly a life-shattering humanity-endangering flaw - certainly not substantial enough to be reported anywhere I've looked - but suggestive that there are/were at least some residual Y2Kesque glitches kicking around.
posted by youhas at 7:58 PM on January 1, 2001
Not exactly a life-shattering humanity-endangering flaw - certainly not substantial enough to be reported anywhere I've looked - but suggestive that there are/were at least some residual Y2Kesque glitches kicking around.
posted by youhas at 7:58 PM on January 1, 2001
Why would computers choke on 31/12/2000?
I mean, technically, what causes that? I can understand the problems with the rollover. Is it a debug flag/error catch like 9/9/99?
And is it fair to call this a Y2K problem, since if it's a debug flag it really has nothing to do with the year 2000 except for that year portion?
Ah well. At least I can wear my horrible Y2K Bug sweatshirt I got for Christmas (my parents are a touch slow :-) now.
posted by cCranium at 6:42 AM on January 2, 2001
I mean, technically, what causes that? I can understand the problems with the rollover. Is it a debug flag/error catch like 9/9/99?
And is it fair to call this a Y2K problem, since if it's a debug flag it really has nothing to do with the year 2000 except for that year portion?
Ah well. At least I can wear my horrible Y2K Bug sweatshirt I got for Christmas (my parents are a touch slow :-) now.
posted by cCranium at 6:42 AM on January 2, 2001
The theory is that they implemented the leap-year calculation wrong, and didn't believe that 2000 had 366 days (which it did).
The rule is "Years divisible by 4 are leap years, except that years divisible by 100 are not leap years, except that years divisible by 400 are leap years after all." So 1900 was not a leap year and 2100 won't be, but 2000 was.
December 31, 2000, was the 366th day of the year. On the other hand, it's not totally obvious why a railroad engine cares what day it is anyway.
posted by Steven Den Beste at 7:33 AM on January 2, 2001
The rule is "Years divisible by 4 are leap years, except that years divisible by 100 are not leap years, except that years divisible by 400 are leap years after all." So 1900 was not a leap year and 2100 won't be, but 2000 was.
December 31, 2000, was the 366th day of the year. On the other hand, it's not totally obvious why a railroad engine cares what day it is anyway.
posted by Steven Den Beste at 7:33 AM on January 2, 2001
But if it worked fine after Feb. 28th (admittedly, an assumption, but a reasonably sound one, since this would've been resolved then if it didn't work), and it was reporting the 30th of December I don't understand why it couldn't get to the 31st.
I wouldn't think that it calculates the number of days and crapped out based on that.
I mean, I can understand how that would choke it if such a calculation were done, I just don't understand why the number of days in a year makes a difference, especially 10 months after the day that should've tossed it.
posted by cCranium at 9:24 AM on January 2, 2001
I wouldn't think that it calculates the number of days and crapped out based on that.
I mean, I can understand how that would choke it if such a calculation were done, I just don't understand why the number of days in a year makes a difference, especially 10 months after the day that should've tossed it.
posted by cCranium at 9:24 AM on January 2, 2001
I just don't understand why the number of days in a year makes a difference, especially 10 months after the day that should've tossed it.
It probably depends on the algorithm the system used to calculate the date. Most Y2K-oriented testing involved the dates 12/31/1999, 1/1/2000, 2/29/2000, and 3/1/2000, but may not have checked 12/31/2000.
A possible scenario: the system keeps track of the current day (be it 4/9, 2/29, or 12/31) as an integer between 1 and 366. From that number, it calculates the current month (1 to 12), and further, the current day. Now let's say the system has a routine to calculate the number of days in a year (to know whether the year has 366 or 365 days). That routine would have to know about leap years and the proper way to correct for them. Let's call that routine X. There's another routine that figures out the current month, based on the number of days in previous months and the current day (1 to 366) we're on. So that function would have to know that in leap years, February has a 29th and in other years it doesn't. Call that routine Y. Programmed years ago, both routines X and Y assumed that 2000 wasn't a leap year.
Now, let's say that during testing the programmers find that Y is returning incorrect values for dates past February 28, 2000. They fix the leap year logic in routine Y, so 2/29/2000, 3/1/2000 and so on all seem to work. If they never test 12/31/2000 specifically, they may never find the bug in routine X. So if the system is being told that today is the 366th day of year 2000 (which routine X will say is not a leap year), unpredictable hilarity would likely ensue.
posted by daveadams at 10:10 AM on January 2, 2001
It probably depends on the algorithm the system used to calculate the date. Most Y2K-oriented testing involved the dates 12/31/1999, 1/1/2000, 2/29/2000, and 3/1/2000, but may not have checked 12/31/2000.
A possible scenario: the system keeps track of the current day (be it 4/9, 2/29, or 12/31) as an integer between 1 and 366. From that number, it calculates the current month (1 to 12), and further, the current day. Now let's say the system has a routine to calculate the number of days in a year (to know whether the year has 366 or 365 days). That routine would have to know about leap years and the proper way to correct for them. Let's call that routine X. There's another routine that figures out the current month, based on the number of days in previous months and the current day (1 to 366) we're on. So that function would have to know that in leap years, February has a 29th and in other years it doesn't. Call that routine Y. Programmed years ago, both routines X and Y assumed that 2000 wasn't a leap year.
Now, let's say that during testing the programmers find that Y is returning incorrect values for dates past February 28, 2000. They fix the leap year logic in routine Y, so 2/29/2000, 3/1/2000 and so on all seem to work. If they never test 12/31/2000 specifically, they may never find the bug in routine X. So if the system is being told that today is the 366th day of year 2000 (which routine X will say is not a leap year), unpredictable hilarity would likely ensue.
posted by daveadams at 10:10 AM on January 2, 2001
Yeah, okay.
I suppose I can buy all that.
It still seems unlikely, but I guess when you've only got a few months to fix a few million lines of code, whatever works is what's used.
posted by cCranium at 11:03 AM on January 2, 2001
I suppose I can buy all that.
It still seems unlikely, but I guess when you've only got a few months to fix a few million lines of code, whatever works is what's used.
posted by cCranium at 11:03 AM on January 2, 2001
« Older Steven Spielberg to receive honorary knighthood | "I wanted to be a mother who bakes. Newer »
This thread has been archived and is closed to new comments
posted by thirdball at 7:40 PM on January 1, 2001