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

[Robert Dewar <dewar@gnat.com>]

In article <3924D3FF.11D8C99A@earthlink.net>,
  "Robert I. Eachus" <rieachus@earthlink.net> wrote:
(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.


What really *is* the situation with Ada 95 compilers. Certainly
in GNAT we chose a representation for Calendar.Time that can
accomodate very wide ranges of times and dates (Calendar.Time
is kept in units of nanoseconds stored in a signed 64 bit value
which represents very wide time ranges -- tens of thousands of
years at least).

It certainly is the case that representations of Calendar.Time
are the worrisome thing here (think for example of such values
written on files). A compiler that has chosen a narrow range
representation for this type has, in my view, made a significant
mistake which will cause nasty compatibility problems later,
but I don't know specifically that any compilers have made
this choice.

Anyone know what other Ada 95 compilers do?

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.