I keep hearing from people (including veteran programmers) there will be some computers problems handling the date this Thursday for September 9, 1999, similar to the y2k problem but on a much smaller scale. They say the date 9999 will be confused with the max value 9999 used by some data processing programs written in languages like SAS and Cobol.
However, I don’t see why there would be a problem because a program would need 6 digits to represent a complete date. Sept 9, 1999, would be 090999, so there would be no conflict with a max value 999999. If a program only used four digits for dates, the program wouldn’t work for dates where the month or day was > 9, such as Sept 10, Oct 5, Nov 14, etc…
Am I missing something, or am I right that there should be no 9999 problem with computer programs?
Unless some truly stupid programmer went to the trouble to write a compression routine on a date field, September 9 will show up internally (on non-Y2K compliant software) as 090999 or 990909. There are routines that will eliminate leading zeroes in displayed fields, but only when there are hyphens or slashes present, (9/9/99 99-9-9), in which case the slash or hyphen breaks up the string of nines. No COBOL or SAS programs should be affected in normal use (unless, as noted, they had really stupid programmers).
(For that matter, the “all nines” usage tended to be a habit in the older Burroughs programs–most of which are gone. Most IBM programs used HIGH-VALUES to identify a series of X’FF’ characters (all bits turned on to “1”) rather than a series of “9999”.)
I can’t say that it cannot happen (lots of stupid people in the world), but unlike the Y2K bug that is a natural outgrowth of expensive storage, a “9999” bug for 09/09/99 would require active stupidity on the part of a programmer.
The only 9/9/99 problems I know of originate in the liveware: users who got into the habit of typing 9/9/99 in date fields to mean “I don’t know” or “irrelevant”. If old databases are still running with such entries in records that were input back when, those 9/9/99 entries will be treated exactly the same as valid 9/9/99 entries (Y2K compliant or not), since the computer has no way of knowing that some schmuck meant “I don’t know” and not Sept 9, 1999 when putting the data in.
In a radio discussion of this topic someone mentioned that April 9th is the 99th day of the year. Some computer programs save dates in that format so the day/year becomes 99/99 for that date in 1999. Since this day has come and gone with no apparent ill-effects it lends credence to those who argue that there will be no problem.
(On the other hand, a confirming instance of a hypothesis does not always support that hypothesis – suppose you set out to prove that there are no men 100 feet tall and you found a man who was 99 feet tall. A confirming instance? Yes. Does it strengthen your hypothesis? No. (Thanks to Martin Gardner))
“non sunt multiplicanda entia praeter necessitatem”
– William of Ockham
Yeah, the weather computers won’t be able to handle it, the weatherperson has to go outside and look at the weather, and we’’ get our first accurate forecast.
In mentioning the “greatest debate of 1999” thread in the “Great Debates” forum, I was hoping to redirect the thinking away from “9999” as a date (which is what I thought it was all about to begin with as well). The “9/9/99” bug isn’t about “9999” being used as a date, it’s about “9999” being used as an end-of-file or end-of-program marker.
I just heard a blurb about it on the news this morning. Just about everyone agrees that few if any systems will be affected.
VegforLife, thanks for referring me to the great debate thread. However, I think the 9999 debate is about it being used BOTH as a date and a max value. That would be a problem because the computer program could not tell which is which.
However, as I explained at the start, I don’t think any program would use just 4 digits for a date. Six digits are needed, as in 090999, so I don’t see any problem with using all 9’s as a max value, 999999.
Why? Can you point us to an article, or a website, or someplace else where the “9/9/99” bug is described as a problem stemming from using the string as a date?
If not, I’ll have to go with the reasonable explanation given in the other thread, as well as the news story I heard this morning.
I think 9.9.99 is what they call a fence-post
date. No one expects a crash by any means, but still the concern exists that something can go wrong…go wrong…go wrong.
I believe the date to simply be one to watch to gauge how the major the hit will be on 1.1.00.
9/9/99 or 99/9/9 European style. No,it’s not symmetrical.Just checking.
I have an instrument at work that is not Y2K compliant.There is no new software for it since 1991. The IS dept big shot told me about my problem.It won’t be able to save data files. I told him no problem.The instrument thinks it is 1993. I never set the clock, I don’t even know where it is.
VegforLife, you can use 9999 as end-of-file marker, or a max value, in a four digit field. However, you can’t use it as an EOF or max-value in a date field that holds the month, day, and year, because you would need at least 6 digits for the complete date. Sept 9, 1999 would be 090999, or 990909, or whatever, but it would be 6 digits. So you can use all 9’s (999999), six of them not four, to your heart’s content as an EOF or max value.
Also, some of you have written maybe there is a problem with people entering 9/9/99 on the screen. However, inside the computer, it would have to convert that entry to 090999. Again, you can’t use 4 digits for a complete date.
I still see no problem with the Sept 9, 1999 date.
