non-Gregorian dates issue

Re: The issue in section 3.2.12 of the draft dated 6 May 1999.  You may wish
to address this issue within bounds by adding a Julian dateTime generated
data type.  While this stems from the Gregorian reform, algorithms are
available for conveniently converting between Islamic and Hindu calendars;
the Chinese calendar is a problematic exception.  Julian dates are also used
directly or with adjustment of the starting epoch in astronomical
calculation.  Thus, this well-established convention will open schema data
types to a wide range of human calendars without introducing excessive
numbers of new generated data types.

This type takes the bounded range [0...2914671.5) and has an optional
constraining facet epoch to denote which Julian epoch applies.  If the facet
does not appear, the first epoch (noon 1 January 4712 BC - noon 31 December
AD 3267) is assumed.  Note the various values for denoting the date of
Gregorian calendar adoption and the date of the new year in pre-Grorian eras
are not required for the data type as this is needed solely for retrieving a
localized value.

-- Stephen Mohr
    Senior Systems Architect, Omicron Consulting

Received on Thursday, 29 July 1999 13:33:55 UTC