Glenn writes:
> I have written a number of systems that used a date to signify no
> expiration, but it was always "99/99/99".

Generally 99/99/99 is a *software* convention, one which you'll find
expressed in source code.  9/9/99 on the other hand is quite often a
*user* convention, one which you won't find special cases for in the
source code, but your database may still be full of these dates.

Why?  Because 9/9/99 is acceptable to a date validation routine while
99/99/99 generally is not.  Thus when a user is prompted for a date,
and they are required to enter one but really want to say "never" or
"forever" or "I'll update this later", 9/9/99 becomes a very convenient
value to use.

Testing around this date is important.  There may be no instances of the
string "09/09/99" in the source code, yet on September 9th of this year,
all of your "never ship" orders might suddenly decide to depart your
warehouse, or you might find yourself suddenly ordering several billion
dollars worth of merchandise :-)

This also points out the importance of testing against the real live
application data (or a complete copy thereof), since something like the
above problem may not be detectable using "test" data.

G. (back from Hawaii)