On 02/13/2013 06:09 PM, John Gilmore wrote:
Tony's rant/lament is apposite, but the date problem goes deeper.
We all distinguish andf use different intgernal and external
representations of signed binary integers; the single-byte internal
value 01111111 is, for example, almost always associated with the
external representation +7; but only the astronomers do this
systematically for dates.
They use Julian Day numbers, which have the Gregorian-calendar epoch
origin noon, -4713 November 24. Dates before and after it are
represented using the sequence
. . . -3, -2, -1, 0, +1, +2, +3, . . .
Any epoch origin can of course be used, and conversions among them are
trivial. The Jewish lunisolar calendar has the Gregorian epoch
origin midnight, -3760 September 7, and a GDN of -1373427; and the
French Revolutionary calendar has the (Gregorian) epoch origin
midnight, 1792 September 22, and a GDN of +654415.
IBM TOD/STCKE values use midnight, 1899 December 31 as their epoch
origin. The mainframe STCKE value is indeed much like a GDN; but for
many uses it has the defect that it is unsigned; proleptic dates,
those before its epoch origin, cannot be expressed.
Less exotically, we can choose the epoch origin of the Gregorian
calendar, midnight, 0000 December 31, to obtain Gregorian Day Numbers.
If we do so, any date in an interval ±5.8 million years about this
epoch origin can be expressed as a signed fullword integer; and dates
back before the big bang and far enough into the future can be
expressed as a signed doubleword.
The advantages of thus distinguishing internal and external date
representations are that the internal representation trivializes
calendar arithmetic and makes the choice of a particular external
representatrion unimportant. You may have as many as you like. To
support a particular external representation, call it X, one writes
just two subroutines: the first converts X values to GDN values, and
the other converts GDN values to X values. If now, we have two
external representations, X and Y, the sequence X==>GDN, GDN==>Y
converts X to Y. Conversion of, say, a Japanese Era-and-Regnal-Year
date into, a Jewish lunisolar-calendar date, which would otherwise be
a formidable undertaking, is again trivialized.
In another piece of misplaced (and parochial) concreteness, the
opportunities presented by the Y2k problem were dissipated in a fog of
ad hoc fixes that have not turned out to be robust: it is an open
secret that the date problems these fixes addressed have persisted.
John Gilmore, Ashland, MA 01721 - USA
IBM refers to the TOD/STCKE epoch origin as 0000 on January 1, 1900,
meaning the midnight that starts January 1 (Jan 1 is implicitly day 0).
Although technically speaking at the infinitesimal instant of midnight
the date is in transition and not fixed, the current international
standard for 24-hour time seems to be clear that 0000 is to be taken as
the beginning of a new day, and if for some reason you wanted to force
association of midnight with the prior day you would call the time 2400
instead of 0000. Perhaps you were thinking TOD conventions force Jan 1,
1900 to be considered as day "1" requiring an origin backup of one day,
but that is not the case.
Inconsistent conventions in 12-hour time about whether midnight should
be considered AM or PM make the date to be associated with midnight in
12-hour notation much more confused -- yet another argument in favor of
using only 24-hour time!
Computer implementations with which I am familiar using day numbering
methods with an epoch origin based on adoption of the Gregorian Calendar
use the start of the first day under the new calendar, the midnight at
start of 15 October 1582 as the epoch origin, and that first day is
day 0. This is possibly because they were inspired by an IBM Systems
Journal article (Ohms, "Computer Processing of Dates Outside the
Twentieth Century", Vol 25, Nr 2, 1986) which suggests that convention.
Astronomers are a perverse lot for choosing an epoch origin at noon
rather than midnight, which makes their concept of "same day" different
from normal discourse.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
