Re: Software Engineering News Brief

[Martin@nezumi.demon.co.uk (Martin Tom Brown)]

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-<year of succession of Emperor reigning in 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  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/