From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,814bd9dd1692da42
X-Google-Attributes: gid103376,public
From: kilgallen@eisner.decus.org (Larry Kilgallen)
Subject: Re: Calling C time function from ADA-95
Date: 1998/06/08
Message-ID: <1998Jun8.192225.1@eisner>#1/1
X-Deja-AN: 360843855
X-Nntp-Posting-Host: eisner.decus.org
References: <3579da75.13533758@enews.newsguy.com>
 <357C141E.D868661F@earthling.net> <6lhnan$1vi$1@goanna.cs.rmit.edu.au>
X-Trace: news.decus.org 897348147 27967 KILGALLEN [192.67.173.2]
Organization: LJK Software
Reply-To: Kilgallen@eisner.decus.org.nospam
Newsgroups: comp.lang.ada
Date: 1998-06-08T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <6lhnan$1vi$1@goanna.cs.rmit.edu.au>, Dale Stanbrough <dale@goanna.cs.rmit.edu.au> writes:
> Charles Hixson  writes:
> 
> "Well, since you asked, the year type of Calendar has a **much** too
>  restricted range.  Saving space by restricting the size of the year that
>  way reminds me of all of the programs that stored only two digits for
>  their year in the '60s, and now their descendants are delighting
>  everyone."
> 
> 
> I always thought the range was chosen to allow for fast leap year 
> calculations (year mod 4, excluding the more expensive mod 100/mod 400)
> rather than to save space. Does anyone have any better knowledge?

I inferred from discussion in comp.lang.ada that there was a goal
of avoiding support for periods of time where popes and kings were
changing the calendar.  Someone said that those with more longterm
needs should write their own calendar package.  There is a lot of
politics in deciding how dates work once you escape the period
covered by the current algorithm.

Larry Kilgallen