🚀 go-pugleaf

In article <447@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes:
>In article <813@ethos.UUCP>, ggw@ethos.UUCP (Gregory Woodbury) writes:
>> The programs may not "need" to handle the dates beyond that 20 year interval
>> but when the programs that are being written now hit the end of the century
>> there are going to be a lot of installations and programs that are going
>> to be suprised come "March 1" to see the computer say "Feb 28, 2000".
>Eh?  You mean Feb 29?  Any computer that doesn't get the 28th right is really
>ill.
>> I had modified the comm system
>> date routines to handle the 2000 non-leap year.
>The year 2000 is a leap year.  Your code was more correct when it wasn't
>modified.
>
>-Ron

This is absolutely correct. The introductory pascal classes at Georgia Tech
have been doing leap year computations as a programming assignment forever
(or at least the 3 years  I've been here). We use the following definition.

"A leap year is any year divisible by 400 or any non-century year that is
divisible by 4".

By this definition the following fragment should compute the proper leap year.

int leapyear(year)
{
   return(!(year % 400) || (!(year % 4) && (year % 100)));
}

(I think this is correct - I'm writing off the top of my head. All corrections
welcome.)