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,cfd23c10fd537a80 X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: Ada Calendar oddity Date: 2000/05/19 Message-ID: <3924D3FF.11D8C99A@earthlink.net>#1/1 X-Deja-AN: 625285880 Content-Transfer-Encoding: 7bit References: <39176D85.603D7AEC@research.canon.com.au> <39178DEA.FD2C20FA@research.canon.com.au> <8f92o1$6v$1@nnrp1.deja.com> <3918BB77.693C70D6@research.canon.com.au> <8fahfv$mgt$1@nnrp1.deja.com> <39230A82.CFA6E18D@earthlink.net> <3924B35E.DC0C9CDF@acenet.com.au> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 958714769 63.24.55.53 (Thu, 18 May 2000 22:39:29 PDT) Organization: The MITRE Corporation MIME-Version: 1.0 NNTP-Posting-Date: Thu, 18 May 2000 22:39:29 PDT Newsgroups: comp.lang.ada Date: 2000-05-19T00:00:00+00:00 List-Id: Geoff Bull wrote: > It was that kind of narrow (focussed on one problem) thinking > that led to the y2k bug! That definitely was not the case. The fact that Year had a constraint, and the range of that constraint were both discussed--at length during the standardization process. The "Ada Doom Date" of December 31, 2099 was well known, with the realization that it would need to be fixed in a subsequent version of the standard. I don't know of anyone who has had problems due to the 2099 limit, but there are several cases where the 1901 limit made Calendar.Time an unsuitable choice for representing birthdates. During the Ada 9X revision, this issue was revisited, and the doom date, as such, wasl removed. An implementation can provide a Calendar.Time type with a range significantly larger than two hundred years and not have to make an explicit check for the doom date in the arithmetic operators. This change is found in RM 9.6(26). As I said in the previous post, I expect that the Year_Number subtype will be extended in a future version of the standard. (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. ;-)