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,
	MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,7b69a8818c20ab9f
X-Google-Attributes: gid103376,public
From: Robert Dewar <robert_dewar@my-deja.com>
Subject: Re: Y21C Bug
Date: 2000/01/02
Message-ID: <84o0g2$u8v$1@nnrp1.deja.com>#1/1
X-Deja-AN: 567436715
References: <84nqbo$q28$1@nnrp1.deja.com>
X-Http-Proxy: 1.0 x24.deja.com:80 (Squid/1.1.22) for client 205.232.38.14
Organization: Deja.com - Before you buy.
X-Article-Creation-Date: Sun Jan 02 17:20:35 2000 GMT
X-MyDeja-Info: XMYDJUIDrobert_dewar
Newsgroups: comp.lang.ada
X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I)
Date: 2000-01-02T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <84nqbo$q28$1@nnrp1.deja.com>,
  reason67@my-deja.com wrote:
> With all the overblown hyper about Y2K, no one has stopped to
> talk about
> the real problem... Ada 83 and Ada 95 both have a Y21C
> problem!


Let's take this seriously for a moment ... In fact the problem
for well written Ada programs is minimal, since the dependence
is entirely hidden in the calendar package. Modifying the
calendar package to have a larger year range is a trivial
upwards compatible change in the spec. So as long as programs
are well written wrt package Calendar, there will be no problems
although recompilation sometime during the next Century may
be required.

One of the advantages of data hiding is precisely that your code
is protected from this kind of implementation change.

Note by contrast that when the Unix date runs out of 32 bits,
this will cause QUITE a bit of disruption to existing programs
and be quite a bit more difficult to fix.


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