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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
