Re: Ada Calendar oddity <was Re: C date package>

["Robert I. Eachus" <rieachus@earthlink.net>]

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.