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

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

Geoff Bull wrote:
 
> It was that kind of narrow (focussed on one problem) thinking
> that led to the y2k bug!

   That definitely was not the case.  The fact that Year had a
constraint,
and the range of that constraint were both discussed--at length during
the standardization process.  The "Ada Doom Date" of December 31, 2099
was well known, with the realization that it would need to be fixed in a
subsequent version of the standard.  I don't know of anyone who has had
problems due to the 2099 limit, but there are several cases where the
1901 limit made Calendar.Time an unsuitable choice for representing
birthdates.

   During the Ada 9X revision, this issue was revisited, and the doom
date, as such, wasl removed.  An implementation can provide a
Calendar.Time type with a range significantly larger than two hundred
years and not have to make an explicit check for the doom date in the
arithmetic operators.  This change is found in RM 9.6(26).

   As I said in the previous post, I expect that the Year_Number subtype
will be extended in a future version of the standard.  (Changing the
range
for Year_Number would require a different representation for variables
of type Calendar.Time.  This is simething that needs to be done slowly,
and with plenty of warning to the compiler vendors.)  On the other hand,
a new Long_Time type would cause fewer upward compatibility problems.
;-)