On 01/09/2011 10:36 AM, john gilmore wrote:
I have been bemused by the Ewing-Gilmartin debate on date representations. It
recapitulates en petit a good many of the jejune Y2k discussions of the past,
complete with their defenses of the indefensible and their characteristic
crackpot realism.
Perhaps even more seriously, it omits to distinguish between
o internal date formats suitable for computation, and
o external date formats, suitable for display to humans or printing.
External formats vary from culture to culture. Even within the Anglo-American
community 'September 2 1925' is universally intelligible but '2 ix 1925'
astonishres many Americans.
Internal date formats are much simpler and not at all controversial among
coloro che sanno. Choose an epoch origin, the putative birth date of Jesus,
that of the Moslem hegira, Scaliger's -4713 January 1 BCE, whatever; give it
the serial number +1, its predecessor days the serial number 0, -1, -2, . . . ,
and its successor days the serial numbers +2, +3, +4, . . . Whatever your
choice, conversion to someone else's choice is trivial; a single
addition|subtraction suffices.
Using DSNs trivializes calendar arithmetic. Moreover, the conversions
o DSN to<somebody's calendar>
o<somebody's calendar> to DSN
are easy too, although they should be encapsulated in subroutines written by a
calendrical-arithmetic specialist (for the same reasons that a sqrt subroutine
should be written by an approximations specialist). DSNs represented as
signed binary fullword values encompass an interval of 5,879,610 Gregorian
years on both sides of the epoch origin chosen, which is adequate for most
practical purposes, but not for geological or astronomical applications, for
which signed binary doubleword values are required.
Why are these four-byte internal date representations not in wide use?
Everyone who knows enough about calendars and dates
to have a right to an opinion agrees that they should be used exclusively. Why
then has this rare consensus been
systematically ignored by the unwashed?
The usual suspects, sloth and ignorance, decisions made by people unqualified
to make them, are, I suppose,
sufficient to explain this avoidance of DSNs. There is probably no need to
invoke the resources of that science
the Italians call dietrologia to identify a villain.
John Gilmore Ashland, MA 01721-1817 USA
...
John,
I respect your breadth of knowledge in many areas, but unless this is
merely intended as very subtle humor, this is way over the top.
Perhaps there may be consensus that the most storage-efficient date
representation is an integer Date Sequence Number (D.S.N.); but there is
certainly no clear consensus on what the origin date should be, and
storage efficiency is not the only consideration. As you point out
there are many potential choices for origin, and the prospect of having
to deal with D.S.N. fields from many different sources, with potentially
conflicting choice of origin points is an error waiting to happen.
On the other hand, the existence of government sanctioned civil
calendars does requires that external interfaces deal with dates in
formats based on those calendars, and in many cases this makes internal
date representations directly based on those date formats a natural choice.
The choice of "best" internal data representations in all cases,
including dates, depends on the manner in which the data will be
manipulated. The only fixed requirement is that the representation
should be as unambiguous as the original source of data.
If the only requirement is merely to save and return a date exactly as
it was originally recorded on a civil document, changing the internal
representation may just be an unjustified waste of resources. If the
primary manner in which the date will be manipulated depends on
relationships with the Gregorian form of the date, it may also be the
case that internal representations directly based on the Gregorian Date
are the most computationally "efficient". It is demonstrably false to
imply that D.S.N. internal representations should be used exclusively,
much less imply sloth, ignorance, and lack of training as the only
grounds for disagreement with that position.
Over the decades there have been many cases where I have had to deduce
the interpretation of fields in records where adequate documentation was
no longer available. When the fields represented dates in formats
directly based on Gregorian Dates, given sufficient number of examples
it was always possible to arrive at a correct interpretation. Had these
fields been integer D.S.N. representations of dates with unknown origin
point, there is nothing in the date representation to give any clue as
to correct interpretation. Sometimes the redundancy in less efficient
date representations is an advantage.
I don't have anything against D.S.N. date representations and use them
where appropriate; but they are simply not always the best choice.
--
Joel C. Ewing, Fort Smith, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
