Re: Y2K Issues

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <717kpq$7cv$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

 > You have to put some bounds somewhere. Allowing dates before 1600 for
 > example (actually 1543 ? not sure) is really asking for trouble
 > (that's when the Julian calendar switched to Gregorian).

   Ooooh boy is that asking for trouble.  I'm not going to try to
create a list of all the dates that various countries switched from
Julian to Gregorian calendars.  I'll just note that it spans five
centuries so far, and there are some countries that still don't use
EITHER Julian or Gregorian calendars.  Greece and Russia are two of
the countries that switched during the twentieth century.

 > Note that for genealogy, you may well need dates before that.

    Note that the problem is not with type Calendar.Time.  As Robert
Dewar pointed out for gnat, the underlying representation is probably
much wider than you need for genealogy or the like.  The problem is
that Year, Split, and Time_Of are defined in terms of the subtype
Year_Number.  Since it seems to be time to discuss enhancements to
Ada, why not a child package of Ada.Calendar like:

   package Ada.Calendar.Extended is

     subtype Year_Number is Integer range _implementation_defined_;
     ...
     function Year (Date: Time) return Year_Number;
     procedure Split(Date: in Time;
                     Year: out Year_Number;
                     Month: out Month_Number;
                     Day: out Day_Number;
                     Seconds: out Day_Duration);
     function Time_Of(Year: Year_Number;
                      Month: Month_Number;
                      Day: Day_Number;
                      Seconds: Day_Duration := 0.0);

   end Ada.Calendar.Extended;

   Of course, it is possible to write the body of such a package in an
implementation independent manner, but making it efficient requires
making it a child of Calendar.  Also, the only thing that has been
stopping me from proposing such a solution is a concern about how to
make use clauses reasonable. 

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...