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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: ff6c8,37e6dbf5e31f6da0
X-Google-Attributes: gidff6c8,public
X-Google-Thread: f43e6,37e6dbf5e31f6da0
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 10db24,37e6dbf5e31f6da0
X-Google-Attributes: gid10db24,public
X-Google-Thread: 1108a1,37e6dbf5e31f6da0
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,37e6dbf5e31f6da0
X-Google-Attributes: gid103376,public
From: Tom Reid <tom_reid-sc661c@email.mot.com>
Subject: Re: Software Engineering News Brief
Date: 1996/11/06
Message-ID: <3280BAFA.1B2F@email.mot.com>#1/1
X-Deja-AN: 195009951
sender: news@schbbs.mot.com (SCHBBS News Account)
references: <55nqea$32a@news2.delphi.com>
content-type: text/plain; charset=us-ascii
organization: TASC
mime-version: 1.0
reply-to: tom_reid-sc661c@email.mot.com
newsgroups: 
 comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu
x-mailer: Mozilla 3.0Gold (WinNT; I)
Date: 1996-11-06T00:00:00+00:00
List-Id: <comp.lang.ada>


tmoran@bix.com wrote:
> 
> >>Ada applications aren't likely to fail any time between now and January 1,
> >>2000, or beyond, for the simple reason that Ada doesn't let programmers
> >>represent dates in two-digit shorthand.
> >
> >Seems rather restrictive.
>   It's also incorrect.  Ada, like any other general purpose programming
> language, of course lets programmers encode dates any way they please.
> Ada *does* have a standard Calendar.Time type with a Year from 1901
> through 2099, which any product calling itself a validated Ada compiler

Let me see if I have this right.  Ada does not have a year 2000 problem
but it does have a year 2100 problem (not that this will affect any of
us).

Anyone know why they didn't make it a span of 255 years and not waste
digits?

> is required to support.  So programmers will usually find it simpler to
> use the standard than to 'roll their own' internal encoding.  The
> standard says nothing about external, human readable input/output
> formats, however, and as an international standard it could hardly demand
> conformance to, say, "MM/DD/YY" or "Fifth Day of November, Year of Our
> Lord Nineteen Hundred and Ninety Six".  ;)

Tom Reid, treid@primenet.com