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: ff6c8,37e6dbf5e31f6da0 X-Google-Attributes: gidff6c8,public X-Google-Thread: f43e6,37e6dbf5e31f6da0 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,37e6dbf5e31f6da0 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,37e6dbf5e31f6da0 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,37e6dbf5e31f6da0 X-Google-Attributes: gid10db24,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Software Engineering News Brief Date: 1996/11/17 Message-ID: #1/1 X-Deja-AN: 197062911 references: <55nqea$32a@news2.delphi.com> <3280BAFA.1B2F@email.mot.com> <563tle$cu7$1@shade.twinsun.com> <56lvss$r82@mulga.cs.mu.OZ.AU> <01bbd490$356f8220$686700cf@ljelmore.montana> organization: New York University newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-11-17T00:00:00+00:00 List-Id: "I agree that it's unnecessary for Ada to directly support dates rtanging over thousands of years, but IMHO the 1900-2099 A.D. limit is just too small. For example, any program dealing with birthdates of people (and I'm thinking mainly in the health care field right now where many patients are elderly), many people alive today were born before 1900. Ada *should* directly support dates widely used in many programs today. Granted, this is a self-correcting problem as those people born before 1900 die off (and, granted, there's not many of them left now as it is), but I honestly can't see why the Calendar package is so limited. Why would it have been so bad to give it a somewhat larger range?" Going back a bit further would have been simple enough, true, assuming everyone agrees that 1900 was not a leap year (is that true, across all governments likely to be involved?) On the other hand, I still think this is a very minor issue. Calendar is basically designed for support of real time (as I noted before it is in the tasking chapter). True it could have been generalized a bit, but there was no sentiment to do so during the revision history, none of the revision requests mentioned it, and no one ever raised this as a significant issue. Whether it would have been worth the incompatibility if someone had, who knows. Meanwhile, an extended date package is a rather trivial thing to write, how about someone who thinks it is important, and therefore must have already done it (or are these all theoretical comments), submitting the code, and we will pop it in the GNAT library!