Subject: | |
From: | |
Reply To: | |
Date: | Fri, 5 May 2000 11:52:01 -0400 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
[said Wes]
>
> In other words, if it's important to you that a compiler support dates
> past 2038, your only assurance is the vendor's promise that their internal
> representation is immmune to any such "flaws" in the O.S. (Or in some
> cases, personal inspection of the compiler source and/or the generated
> code.)
>
I cannot see how it's possible to immunize Ada completely. Obviously
a compiler developer can choose a representation for Ada.Calendar.Time
that is immune, and so with respect to time operations _within the
package_ there is no problem.
The glitch comes from talking to the world outside the package.
Unless I'm seriously off-base here, in implementing the function
Ada.Calendar.Clock, you can't read the clock without reading the
clock.
So you are, inherently, at the mercy of the underlying platform.
You might be able to end-run the _OS_ clock service and go straight
to the hardware clock, but suppose the hardware itself is noncompliant?
Mike Feldman
|
|
|