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: f43e6,37e6dbf5e31f6da0 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,37e6dbf5e31f6da0 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,37e6dbf5e31f6da0 X-Google-Attributes: gid10db24,public X-Google-Thread: ff6c8,37e6dbf5e31f6da0 X-Google-Attributes: gidff6c8,public X-Google-Thread: 1108a1,37e6dbf5e31f6da0 X-Google-Attributes: gid1108a1,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Software Engineering News Brief Date: 1996/11/16 Message-ID: #1/1 X-Deja-AN: 196893138 references: <55nqea$32a@news2.delphi.com> <3280BAFA.1B2F@email.mot.com> <563tle$cu7$1@shade.twinsun.com> organization: New York University newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-11-16T00:00:00+00:00 List-Id: Paul Eggert says "... which is why the next version of Ada should support Gregorian dates all the way back to at least the year 1, if not before. Trying to match the historical introduction of the Gregorian calendar leads to severe politico-technical problems. For an example of this see my May 1995 comp.risks article about Sybase's historically naive practice of arbitrarily rejecting Gregorian dates before 1753." That sounds silly to me. This is a highly specialized requirement that should be provided by auxiliary packages, not by the central package for dealing with near by dates that is primarily intended for use in control of time related processing (note that Calendar is still in the tasking chapter, even in the new RM. Also, Gregorian dates are quite tricky, because the change over in the calendar happened at different times in different parts of the world, so you need detailed geo-political localization for such processing. Again, much more suitable for some auxialiry package than for Calendar, which does not even have time zone support. As for prohibiting implementations from extending the range, yes, this is quite deliberate, but you state it in a peculiar manner. There is nothing to stop an implementation from providing an extended calendar package with whatever range of dates is needed, and this can easily be written s a portable package, but you certainly do NOT want different implementations to implement the standard library with such gratuitous variations. Ada is much more concerned with portability than you are I guess. If there is really a need for such extended calendar support from real Ada programmers writing real Ada programs, rather than just in the context of CLA discussions, then such packages will appear, along with many other useful packages, you cannot put support for all kinds of specialized requirements into the language. I would say this is a perfect example of specialized needs that should NOT be met in the standard language. I would far rather have Ada implementors working to get their implementations more efficient and more robust than wasting time in the library trying to figure out when the switch to Gregorian dates happened in Lithuania. In the GNAT world, people are very free in making suggestions about things they would like to see in GNAT. No one ever mentioned this, so I find that at least one measure of its extremely limited value.