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: 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: "Norman H. Cohen" Subject: Re: Software Engineering News Brief Date: 1996/11/18 Message-ID: <3290A899.2052@watson.ibm.com>#1/1 X-Deja-AN: 197261710 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> content-type: text/plain; charset=us-ascii organization: IBM Thomas J. Watson Research Center mime-version: 1.0 reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu x-mailer: Mozilla 3.0 (Win95; I) Date: 1996-11-18T00:00:00+00:00 List-Id: Larry J. Elmore wrote: > 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. You are confused about the "direct support" that Ada provides for dates. Like any general-purpose programming language, Ada allows a programmer to construct any representation of dates appropriate for his application, e.g. a string of the form yyyymmdd, along with a set of subprograms to manipulate that representation. In addition, since Ada is (among other things) a real-time programming language, the standard Ada library includes a package named Calendar with one particular representation--a type named Time capable of representing any time from the year 1901 to the year 2099 to an accuracy of 20 milliseconds or better (with a recommendation that implementations provide a representation accurate to 0.1 milliseconds if the underlying system supports it). The operations of type Time are: - decomposing a Time value into year, month, day, and seconds - composing a Time value from these components - comparing two Time values for <, <=, = >=, or > - subtracting two Time values within 24 hours of each other to obtain a difference in seconds (of type Duration) - adding or subtracting a number of seconds in the range -86,400 to 86,400 (86,400 seconds = 1 day) to a Time value to obtain a new Time value That's it. There are no operations to add a specified number of days, years, or months to a Time value to obtain a time value, no operations dealing with days of the week, etc. Sure there are applications that require such capabilities, but the Calendar package was never meant for those applications. Unless your health-care application has a requirement to pinpoint the birth of somebody born in 1899 to within 20 milliseconds, I can't imagine why you would consider the type Calendar.Time as the appropriate representation for birthdates. On the other hand, Calendar.Time might be appropriate for a time-machine control program if only the range were wider... ;-) -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen