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: ff6c8,37e6dbf5e31f6da0 X-Google-Attributes: gidff6c8,public X-Google-Thread: 103376,37e6dbf5e31f6da0 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,37e6dbf5e31f6da0 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10db24,37e6dbf5e31f6da0 X-Google-Attributes: gid10db24,public From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) Subject: Re: Software Engineering News Brief Date: 1996/11/17 Message-ID: <56lvss$r82@mulga.cs.mu.OZ.AU>#1/1 X-Deja-AN: 196972773 references: <55nqea$32a@news2.delphi.com> <3280BAFA.1B2F@email.mot.com> <563tle$cu7$1@shade.twinsun.com> organization: Comp Sci, University of Melbourne newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-11-17T00:00:00+00:00 List-Id: dewar@merv.cs.nyu.edu (Robert Dewar) writes: >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. I don't think it is a highly specialized requirement. I think the requirement for a generic date type the works over a large range of dates is quite common. Many programs let users enter dates, and putting strict requirements on the dates entered is not unlike assuming that no-one will ever want to enter a line with more than 80 characters. >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. Gregorian dates aren't tricky, the change-over from other systems is tricky. That's why Paul Eggert suggested supporting Gregorian dates only, even for dates before the Gregorian system was used. >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. You misunderstood what Paul Eggert was saying. His suggestion would *not* require implementors to figure out when the switch to Gregorian dates happened in Lithuania or anywhere else. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.