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.6 required=5.0 tests=BAYES_20,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cfd23c10fd537a80 X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: Ada Calendar oddity Date: 2000/05/17 Message-ID: <39230A82.CFA6E18D@earthlink.net>#1/1 X-Deja-AN: 624702814 Content-Transfer-Encoding: 7bit References: <39176D85.603D7AEC@research.canon.com.au> <39178DEA.FD2C20FA@research.canon.com.au> <8f92o1$6v$1@nnrp1.deja.com> <3918BB77.693C70D6@research.canon.com.au> <8fahfv$mgt$1@nnrp1.deja.com> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 958597669 63.24.60.10 (Wed, 17 May 2000 14:07:49 PDT) Organization: The MITRE Corporation MIME-Version: 1.0 NNTP-Posting-Date: Wed, 17 May 2000 14:07:49 PDT Newsgroups: comp.lang.ada Date: 2000-05-17T00:00:00+00:00 List-Id: Robert A Duff wrote: > The reason for the range 1901..2099 is that leap year calculations are > simpler (and more efficient) in this range -- in this range, all years > divisible by 4 are leap years (including 2000). 1900 and 2100 are not > leap years. True, but that was the reason it was that way in Ada 83, when avoiding the Y2K bug was a big deal. Incidently, note that even in that range there are countries that switched from the Julian to the Gregorian calendar, so dates in early 1900's have to be taken with a grain of salt. There was some discussion of changing the range for the year subtype in Ada 95, but it was felt to be unnecessary. However, several changes in the details were made so that Ada.Calendar.Time does not have an imposed limit. This was felt to be a minor upwardly compatible change, while forcing existing compilers to change the underlying types to support some fixed wider range would have imposed much more work. This allows a Split procedure (probably a in child package of Calendar) to be provided by an implementation which supports a wider range of years. Note also that it would be nice to have child packages for other calendars, such as Chinese, Japanese, Jewish, and Muslim. I have done some work on how to provide such packages, but there are serious problems of definition if you try to extend the date ranges significantly. It doesn't make much sense to take Gregorian dates back before the 16th century, but the Julian calendar needs to carefully deal with the lack of a year zero, and there have been several calendar "reforms" which moved things around. It is nice to be able to use the same date as someone living in that era would have--but it is not a very easy job. In some cases there are suspected mis-correlations of hundreds of years. By Ada0X or Ada1Y or whatever, there should be a much wider agreement on how the Ada.Calendar.Year subtype should be redefined, and maybe on a rich set of subpackages to deal with other calendars.