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=2.1 required=5.0 tests=BAYES_20,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: 103376,37e6dbf5e31f6da0 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,37e6dbf5e31f6da0 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,37e6dbf5e31f6da0 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10db24,37e6dbf5e31f6da0 X-Google-Attributes: gid10db24,public X-Google-Thread: ff6c8,37e6dbf5e31f6da0 X-Google-Attributes: gidff6c8,public From: Martin@nezumi.demon.co.uk (Martin Tom Brown) Subject: Re: Software Engineering News Brief Date: 1996/11/19 Message-ID: <848393101snz@nezumi.demon.co.uk>#1/1 X-Deja-AN: 197428176 references: <55nqea$32a@news2.delphi.com> <3280BAFA.1B2F@email.mot.com> <563tle$cu7$1@shade.twinsun.com> <56q5e3$ntv@gaia.ns.utk.edu> x-mail2news-user: Martin@nezumi.demon.co.uk x-mail2news-path: nezumi.demon.co.uk organization: Nezumi reply-to: Martin@nezumi.demon.co.uk newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-11-19T00:00:00+00:00 List-Id: In article <56q5e3$ntv@gaia.ns.utk.edu> %%spam "Matt Kennel" writes: > Robert Dewar (dewar@merv.cs.nyu.edu) wrote: > : 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. Yes you are right. This thread seems to be a argument so far which confuses details of the input/output package for dates with the internal machine representation of the entity. Remember that in some countries US style dates MM/DD/YYYY are not standard and so DD/MM/YYYY is used in the UK and YY'/MM/DD in Japan (YY' is YYYY-) > 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. The history of the derivation of accurate time systems is too messy and off topic to deal with here. It is worth taking a look at the Explanatory Suppliment to the Astronomical Ephemeris & Nautical Almanac. There is a very throrough discussion of how the various civil and astronomical Ephemeris time systems and SI definitions are linked. The same is true for details of geographic adoption of calendars (problems also exist in this area of knowing *where* historic borders actually were located in some hotly disputed areas). > This is a *solved* problem for astrophysical ephemerides. Indeed and the solution has existed for a very long time. > Ok, we now have absolute days, counting in integers. > I believe this is called "Julian date". Yes - the "Julian Day Number" is defined on the integers, and its extension "Julian Date" is defined on the reals to include fractions of a day to specify time of observation. Note it was defined so that from Greenwich the JD would change at midday so astronomical observations on a single night get the same JD. > 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 heartily agree, but then being a scientist and former astronomer based in the UK I could be accused of Greenwich-o-centric bias here. > I wonder if this also addresses the question of whether > "math or science" are useful for computer programmers. I think it is actually a beautiful example of the relevance of existing knowledge outside computing to software problems. It is worth also noting here that in addition to the Y2K problem in 1988 *and* 1992 leap year related faults occurred in various banking systems which caused chaos both on 29/2 and 31/12. It appears this leap year may be OK - so far so good anyway. Regards, -- Martin Brown __ CIS: 71651,470 Scientific Software Consultancy /^,,)__/