This may have indirect implications on the to electric industry (most likely in billing).

It has been accepted almost as an axiom that September 9, 1999 was to present a computer processing problem because of the series of 'nines' in the date possibly being confused with the old "999" end file command used by COBOL and other older programs. Year 2000 experts told us early on that 9/9/99 could trigger problems similar to Y2K because of the "all nines" date. Files could end, computers could shut down.

Computers with date fields not yet expanded for Y2K read dates as MMDDYY, however. That means a computer sees September 9, 1999 as 09/09/99, not 9/9/99. Consequently, there will be no dates next year with 'all nines' in it.

This new understanding has little impact on the all important embedded systems problem, but it is still generally construded as being good news. Still, I find it quite amazing the "experts" didn't pick up on this revelation early on. And it makes me realize the challenges of comprehending the nuances of this date change issue.

-- Anonymous, November 18, 1998

Answers

The issue is not whether "the computer" sees 999999, 990909 or 090999, the issue is whether the software has been written to consider the use of "9"s as signifying something special (e.g., an end-of-file condition). I think it is perfectly reasonable that a programmer, who on the one hand wanted to use this "9"s convention to signify a special action, but at the same time wanted to make sure that there would be no problem with VALIDATION routines that would check to ensure that the month was 1..12, the day 1..31, etc., would indeed conceivably use "09" for month and day.

Did this actually ever happen? Is this really a problem? Personally, I have no idea, other than it has been claimed that it has. The only point that I am trying to make here is that to dismiss the claim because the date string for Sept 9, 1999, is not 999999, is not warranted.

-- Anonymous, November 18, 1998

Coincidentally, there is an article addressing this very topic on today's Westergaard Year 2000 site (www.y2ktimebomb.com). The author states that problems related to September 9, 1999 are possible but not probable. My own COBOL programming experiences tell me that such problems are highly UNLIKELY in that language.

-- Anonymous, November 18, 1998

Peter, I agree. Although it's been a long time since I've done any COBOL programming, I seem to remember that all six digits in a date defined as a PIC field would have to be 9's for the problem to manifest itself. So more than likely, most COBOL programs won't have a problem with 09/09/99. However, other languages may not be so forgiving. Guess we'll have to wait and see...

-- Anonymous, November 19, 1998

I suspect the real problem will come on the 99th day of 1999, which is some time in April (I believe). There are probably many systems out there that keep a day-in-year count, and in that case (depending on the data structure used) it could well end up being 9999.

Of course, April 1st is the first day of fiscal year 1999 here in Canada, and that might cause a few more problems right around that time...

-- Anonymous, November 19, 1998

It is highly unlikely that either a date value of 09999 (DDDYY) or 090999 (MMDDYY) will cause a problem in COBOL programming. As stated previously any field tested for End Of File (EOF) or any other special condition would normally be tested for ALL 9s ie 999999. The second reason is that a Date Field is less likely to be used for this purpose. The only way it would cause a problem would be if the EOF was signified by merely testing the YY. Obviously a program can be written to do anything. The other y2k problems (ie date arithmetic, projecting future dates, reverting to 1900 etc) are real however.

-- Anonymous, November 19, 1998

In the late eighties I was a maintenance programmer on a DOS based accounting suite. This packaged software when first installed would run for a 30 day period from installation. The user had to phone the company helpdesk and receive a number password to unlock the software for unlimited use. When the password was entered the expiry date in the software was changed to expire on in 99. I don't recall the exact date, it could have been 01/01/99, 09/09/99 or 31/12/99, but the bottom line is that if anyone still uses that software I know that they won't be for much longer.

-- Anonymous, November 30, 1998