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.6 required=5.0 tests=BAYES_05,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: ff6c8,37e6dbf5e31f6da0 X-Google-Attributes: gidff6c8,public X-Google-Thread: f43e6,37e6dbf5e31f6da0 X-Google-Attributes: gidf43e6,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: mbk@caffeine.engr.utk.edu (Matt Kennel) Subject: Re: Software Engineering News Brief Date: 1996/11/18 Message-ID: <56q5e3$ntv@gaia.ns.utk.edu>#1/1 X-Deja-AN: 197237269 references: <55nqea$32a@news2.delphi.com> <3280BAFA.1B2F@email.mot.com> <563tle$cu7$1@shade.twinsun.com> followup-to: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu organization: University of Tennessee, Knoxville and Oak Ridge National Laboratory reply-to: %%spam repellent: remove this prefix%%kennel@msr.epm.ornl.gov newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-11-18T00:00:00+00:00 List-Id: Robert Dewar (dewar@merv.cs.nyu.edu) wrote: : 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. Let's stop complaining about the problem and start thinking about its fundamentals correctly. There are indeed universal and uniform notions of "date", for example, counting absolute days, defined perhaps as count of maximum solar altitude over some fixed longitude. This is a *solved* problem for astrophysical ephemerides. (You also have to decide whether you care about the extra 'apparent' angular rotation from the orbit of Earth around Sun in addition to the spin rotation; for human notions of 'date', the answer is "yes"). Ok, we now have absolute days, counting in integers. I believe this is called "Julian date". Quoting from 'Numerical Recipes in C', pg. 12, Astronomers number each 24-hour period, starting and ending at noon, with a unique integer, the Julian Day Number. Julian Day Zero was a very long time ago; a convenient reference point is that Julian Day 2440000 began at noon of May 23, 1968. Julian dates can be added and subtracted like natural integers. Given this representation, the translation to MM/DD/YY is a *transformation layer* (model vs. view) depending on location, time, religion, nationality, et cetera. E.g. RussianAndSovietOrthodoxDateTranslator, WesternEuropeanDateTranslator, FrenchRevolutionDateTranslator, RomanEmpireDateTranslator I wonder if this also addresses the question of whether "math or science" are useful for computer programmers. -- Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/