what about sept 9, 1999 [9999]

greenspun.com : LUSENET : HumptyDumptyY2K : One Thread

I have been told that Sept 9, 1999 [9999] is the end of time for some computers. Does anybody know if this will an earlier version of the [y2k] problem?

-- john mattingly (jmattingly@mail.gcnet.net), August 24, 1999

Answers

Hi John,

The 9th September 1999, or '9/9/99', bug you talk about has, I've learnt, been hyped up a lot. While it may cause some problems, very likely these problems will be minor and no where near the magnitude of the Y2k bug.

The main facet of the 9/9/99 bug (I've also learnt there may be more) is the concern that many programmers, in the old days, used the date 9/9/99 as a special marker for various things. For example, a programmer might have used 9/9/99 to indicate the last record in a personnel database. This was done in an effort to save computer memory and programming instructions; just as the Y2k bug was born in an attempt to save memory. And just like the Y2k bug, the programmers never thought their programs would still be around in 1999, so they didn't consider this potential bug to be a problem. But now many people are concerned that when programs written in a such a way see the date 9/9/99 they will behave unpredictably or crash.

However, there is a flaw in this whole issue. Generally the old programs used 6 digits to record a date -- two for the day, two for the month, and two for the year. That means the date 9/9/99 would be represented, inside the computer, as '090999'. When you think about it, it is doubtful (although possible) that a programmer would have used such an unusual number as a special marker. More likely they would have used '999999'; and since this number does not translate to any real date, there is no chance of the program experiencing problems with it. Or they may have used '000000', which also has no real date representation; or something else.

In short the 9/9/99 bug will most likely be a fizzer. Incidentally there are other facets to this bug, as I mentioned before, which may cause problems. For a comprehensive description of the whole issue I advise you to read the following document (written by Ed Yourdon himself, I believe):

http://www.garynorth.com/y2k/detail_.cfm/5803

Hope I've been helpful!

-- Jason Quarry (onca@hotmail.com), August 25, 1999.


I've repeatedly said that in 25-odd (very odd) years of mainframe and PC programming, I've never seen a program sensitive to 9/9/99. I've probably seen many sensitive to 99/99/99, but that date is never going to get here.

HOWEVER, 12/31/99 is used in EXACTLY the way the 9/9/99-worriers are talking about. That is, 12/31/99 is used to mark end-of-file, or as "high-values" in a sort key. It will cause exactly the kind of error people are unjustifiably worried about for 9/9/99.

But when 12/31/99 gets here, we'll be responding to it on 1/1/2000 along with all the other y2k errors (i.e., the zero-year errors) and so the uniqueness of the 12/31/99 error will sort of be lost in the dust and shuffle. Still, it's a separate problem with its own symptoms. The programmers who fix it will know.

-- bw (home@puget.sound), August 25, 1999.


We should know soon ! I expect a few problems.

In contradiction with previous reply, I do know of a number of programmers who used routinely (and even as a programming standard in large programming shops) 9/9/99 or 0/0/00 in the date field to mark records as either last record to be processed or record that should be skipped. Cobol does not have specific date routines (at least the older versions did not). This means that routines or libraries to handle dates were also written by individual programmers, and in such a way that 9/9/99 would be same as 09/09/99. Its a bit more complex than that, since usually one would convet a date into a number, and the reformat the number back to a date, but the end result is the same.

-- Scheidt (robert.scheidt@unisys.com), August 31, 1999.


Moderation questions? read the FAQ