Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!oliveb!hplabs!hao!nbires!rcd
From: rcd@nbires.UUCP (Dick Dunn)
Newsgroups: net.lang.c
Subject: Re: Calendar Functions (simpler leap year calculation)
Message-ID: <573@opus.nbires.UUCP>
Date: Thu, 18-Sep-86 01:17:02 EDT
Article-I.D.: opus.573
Posted: Thu Sep 18 01:17:02 1986
Date-Received: Sat, 20-Sep-86 01:00:03 EDT
References: <206@cascade.STANFORD.EDU> <1229@loral.UUCP> <34@vianet.UUCP> <1193@ttrdc.UUCP>
Distribution: net.lang.c
Organization: NBI,Inc, Boulder CO
Lines: 20
Summary: hello, Gregory?

In article <1193@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes:
> In article <34@vianet.UUCP>, devine@vianet.UUCP (Bob Devine) writes:
[example of leap-year test covering 4, 100, 400]
> >  While this works, it is overkill.  Unless you believe that your
> >code will make it to the year 2100, a simple test for divisibility
> >by 4 is sufficient...
> Butbutbut... whattabout code which deals with things that are of concern
> over more than a few years' scope, such as positions of the heavenly bodies?

Butbutbut...the argument to the procedure was an int year, apparently CE.
So if you're worrying about getting it absolutely correct, don't forget the
Gregorian correction!  Leap years are child's play next to that one.

No, really, look:  FIRST, decide the domain for the function.  THEN design
the function to work well in that domain.  IF someone tells you that the
function doesn't work for his problem (outside the domain of the function),
tell him that hammers don't work for sawing wood, either.
-- 
Dick Dunn    {hao,ucbvax,allegra,seismo}!nbires!rcd	(303)444-5710 x3086
   ...Are you making this up as you go along?