Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!nike!ucbcad!ucbvax!decvax!mcnc!ethos!ggw
From: ggw@ethos.UUCP (Gregory Woodbury)
Newsgroups: net.lang.c
Subject: Re: calculating leap years
Message-ID: <813@ethos.UUCP>
Date: Fri, 10-Oct-86 17:13:41 EDT
Article-I.D.: ethos.813
Posted: Fri Oct 10 17:13:41 1986
Date-Received: Sat, 11-Oct-86 21:31:26 EDT
References: <40@vianet.UUCP>
Reply-To: ggw@ethos.UUCP (Gregory Woodbury)
Distribution: net
Organization: The Humanities Forum @ ethos, Durham, NC
Lines: 33

<where is the line-eater hiding - is it a wumpus? (or a boojum)>

In article <40@vianet.UUCP> devine@vianet (Bob Devine) writes:
>
>  You are missing the point: I wrote that doing the simple check for
>divisibility by four is sufficient for most programs.  I would bet that
>99% of programs don't need to handle dates with precision outside of
>+/-20 years from the current date.  Geneology programs might want more.
>Astronomical programs almost certainly do.  In the same sense, not all
>arithmetic calculations need be done in double precision.

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".

In at least one industrial control system, there is going to be a discrepancy
between the VAXen and their comm controllers.  I had modified the comm system
date routines to handle the 2000 non-leap year, and was told to take it back
out "because the system won't be in use that long."  That's the worst excuse
I have ever heard for managemental incompentence - how many systems (especially
commercial ones) are still running programs that were written more than 20 years
ago [more than you might think] just because they never can be bothered to
re-implement (when emulation is available).
------------------------------------------
Gregory G. Woodbury				The usual disclaimers apply
Red Wolfe Software and Services, Durham, NC
{duke|mcnc|rti-sel}!ethos!ggw

------------------------------------------
Gregory G. Woodbury				The usual disclaimers apply
Red Wolfe Software and Services, Durham, NC
{duke|mcnc|rti-sel}!ethos!ggw