Re: YEAR 2000 Problem with existing Databases

Paul Roberts <proberts_at_isc901.jsc.nasa.gov> writes:  

>Well, Bruno, the main problem is that everyone has sat around on their
>asses and failed to plan for the turn of the century! Those two-digit
>dates stored as something else are going to cause a headache. The most
>iritating part of the whole thing, though, is that some people won't
>even code for the year 2000 NOW when its only five years away.
>
>BTW, you should know that the year 2000 is NOT a leap year in the
>Gregorian calendar!!! I know that its divisible by four, but there's
>this little exception to that rule that says if its divisible by 400,
>its not really a leap year.
 

What is REALLY IRRITATING is this confusion about the leap year rule.  

Years divisible by 4 are leap years (1992, 1996, ... United States presidential election years), EXCEPT those divisible by 100 (1800, 1900) EXCEPT EXCEPT those divisible by 400 (1600, 2000).  

Thus, 2000 will DEFINITELY BE a leap year.  

I expect (and almost hope) that software developers get sued for malpractice when financial systems screw up due to the OTHER year 2000 problem, which is only storing 2-digit years.  

• Rick --

(Rick Rutt is a system architect living and working in Midland, Michigan.) Received on Wed Dec 20 1995 - 00:00:00 CET