I've read, even in the local paper, that April 9th is a date to watch. It's obvious why september 9, 1999 could be a problem (9/9/99) and I understand that April 9th is the 99th day of the year, but I don't understand why that could triger problems. Do computers know it's the 99th day of the year, do they read it that way? Is it just the fact that they will be three nines in the date? I have found the explainations to the April 1 questions here most helpful. (at least those that respond in a common sense way)and look forwad to some insite on this date. Thanks in advance.

-- another lurking GI (Preparing@CentralOhio.com), April 05, 1999

Answers

This has to do with Julian date format, where the day of the year is stored and processed as 99 (for 4/9/1999) as you pointed out. So, since the year is 1999, if you have a truncated year format of just two digits prefixed by or concatenated with the julian date of 99, then what you have is the value 9999. This value has been used by some programmers, especially in some of the older languages such as COBOL, as a trigger for special processsng. It really depends on the logic of the program and if the programmer uses 9999 in the fields being referenced to do something special - like purge records, stop processing, etc.

Will this actually cause problems? All I know is that it is in fact possible, depending on how the combined Julian day and year are used by the program. Like everything else with Y2K, we wait and see. Hope this helps, Rob.

-- Rob Michaels (sonofdust@com.net), April 05, 1999.

Sorry Rob, A Julian date is usually a 5 character field. It will be 99099, not 9999. This is another one of those over-blown rumors, IMHO. Once again, they call it the Y2K problem for a good reason, not the various dates in 1999 problem. <:)=

-- Sysman (y2kboard@yahoo.com), April 05, 1999.

Sysman: You are right. I was unclear in that there are potentially instances where the Julian date could be redefined into a different format and this is what I was referring to. The redefined format could result in a value of 9999.

-- Rob Michaels (sonofdust@net.com), April 05, 1999.

Hi Rob. Yes, anything is possible, although I've never seen a Julian date redefined in this way in my 31 years. Julian dates are often used because they sort nice, and truncating the day part would no longer work (991 99100 etc.). Allow me to re-post my reply to the 09/09/99 question, since it's the same idea:

First, it is highly unlikely that a date field would be used for delete, end-of-file or whatever. Operating systems have specific "flags" to do these sort of things. It has been suggested that 09/09/99 would be used for this type of stuff, since it is a valid date and would pass any date validation routines, whereas 99/99/99 is not a valid date. However, the programmer would be very aware of this, and either would never call the validation routine in this case, or use 99/99/99 to force an exception and take appropriate action. So I think the odds of this being a problem are very slim at best. <:)=

-- Sysman (y2kboard@yahoo.com), April 05, 1999.

April 9th 1999, Some electrical testing.

-- && (&&@&&.&), April 05, 1999.

No &&, same as the communications test for the electrical system. <:)=

-- Sysman (y2kboard@yahoo.com), April 05, 1999.

Sysman;

Sorry to do this but, for the first time, you are not quite right. it may be "Highly Unlikely that the firld was used for flagging" (rough quote) but I know of at least 40 systems in two organizations that, if they haven't been remediated, DO use this technique. The organizations view change as OK if it happens on a geological time scale, and movement must be glacial to happen at all, so I don't hold a lot of hope ref remediation.

chuck

-- Chuck, a night driver (reinzoo@en.com), April 06, 1999.

OK Chuck, I stand corrected. Must be my tunnel vision. That's the problem with this whole mess. There are so many ways of doing things, and no two programmers think alike. Thanks for your input. <:)=

PS - Not bad, 1 wrong out of 1000+ (grin)

-- Sysman (y2kboard@yahoo.com), April 06, 1999.

Allow me to refer you to the following on the all-nines dates:

http://www.y2ktimebomb.com/Computech/Issues/lcore9846.htm http://www.y2ktimebomb.com/Computech/Issues/lcore9850.htm

and to the following on the April 9 NERC exercise:

http://www.y2ktimebomb.com/Industry/Utilities/lcore9914.htm

-- Lane Core Jr. (elcore@sgi.net), April 06, 1999.