From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,92471489ebbc99c6
X-Google-Attributes: gid103376,public
From: Niklas Holsti <nholsti@icon.fi>
Subject: Re: Y2K Issues
Date: 1998/10/19
Message-ID: <362B67B7.3A3B2CC6@icon.fi>#1/1
X-Deja-AN: 402862893
Content-Transfer-Encoding: 7bit
References: <362B53A3.64E266AB@res.raytheon.com>
Content-Type: text/plain; charset=us-ascii
Organization: Space Systems Finland Ltd
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1998-10-19T00:00:00+00:00
List-Id: <comp.lang.ada>

John J Cupak Jr wrote:
> 
> Greetings!
> 
> I hope this question has not been posted yet. If so, I missed it even
> though I looked in Deja News.
> 
> What is the effect of the Y2K problem on date calculations in Ada (both
> 83 and 95).
> 
> If this is a compiler vendor issue, what compilers have "certified"
> their date calculations Y2K correct?

At least the TLD Ada 83 cross-compiler from Sun Solaris to
MIL-STD-1750A. TLD states that this compiler, the code it generates
and the RTS work correctly across Y2K. I have used this compiler
in the ENVISAT project for the European Space Agency. ENVISAT
launch date was originally late 1999, I believe it has now moved
to the following year...

I would expect most Ada compilers and RTSs to be Y2K-compliant, in
part because the problem is brought out by the Ada.Calendar type
declaration you quoted.

Niklas Holsti