Some examples from papyri.info of information concerning the
observation about "significant body of data"
and 29 February in BCE dates.
Simply meant to illustrate a way that has been found for dealing with
The solutions function. Whether they are beyond blame is another matter
all the best
Zitat von "C. M. Sperberg-McQueen" <[log in to unmask]>:
> Pedantry alert: correcting careless phrasings lest they cause unnecessary
> confusion. Ignore unless you actually care about the details.
>> On Oct 31, 2018, at 8:55 AM, C. M. Sperberg-McQueen
>> <[log in to unmask]> wrote:
>>> On Oct 31, 2018, at 7:07 AM, Hugh Cayless <[log in to unmask]> wrote:
>>> I hate to say it, but it depends...on what schema language you?re
>>> using. Because of the issues outlined here
>>> https://github.com/TEIC/TEI/issues/1344, whether your dating
>>> system has a year zero or not will depend on whether you use Relax
>>> NG (no year zero) or XML Schema (has year zero). If there is a
>>> year zero, (CE) centuries should be X00-X99. It?s my sense that
>>> most TEI rely on Relax NG.
>>> And, yes, this is completely bonkers.
>> Neither the proleptic Gregorian calendar nor the Christian version
>> of the Julian calendar has a year zero. The discrepancies in validator
>> behavior noted in the Github issue referred to relate not to whether
>> there is a year zero, but how to validate years of the form ?0000?,
>> ?-0001?, ?-0002?, etc.,
> read: about how to validate date values whose year takes the lexical
> form ?0000?, ?-0001?, ?-0002?, etc.
>> The initial version of XSD, working from an
>> edition of ISO 8601 which does not specifiy an interpretation for
>> year numbers preceded by a minus sign and from the historical fact
>> that in the year numbering of the common era the year 1 of the
>> common era is immediately preceded by the year 1 BCE, assigned
>> the meaning 1 BCE to year -0001, 2 BCE to year -0002, etc.
> read: assigned the meaning 1 BCE to the lexical representation ?-0001?,
> 2 BCE to the lexical representation ?-0002?, etc.
>> proved unfortunate, as astronomers (perhaps the most numerous
>> users of the proleptic Gregorian calendar) have since the Cassinis
>> used the number 0 to represent 1 BCE, -1 to represent 2 BCE, etc.,
>> as this simplifies the calculation of data intervals which cross the
>> epoch. The later version of ISO 8601 specifies that year 0000
>> denotes 1 BCE, -0001 denotes 2 BCE, etc.,
> read: specifies that ?0000? is the string denoting the year 1 BCE,
> ?-0001? is the string denoting 2 BCE, etc.
>> and XSD 1.1 changed the
>> definition of the date types accordingly, since as far as we could tell
>> no one at that time had any significant body of data that used the
>> earlier convention. Validation is affected by this only in the cases
>> of (a) dates in the year 1 BCE
Signifcant body of data.
This is simply a note of data that we have in papyri.info.
If one goes to
then go to half way down to "Date before" and choose the value "1 CE"
one finds 15443 files which contain documented BCE dates
An example is
<origDate notBefore="-0114" notAfter="-0113">114/113 B.C.?</origDate>
<origDate notBefore="-0199" notAfter="-0100">2nd century B.C.</origDate>
This is data used against the tei-epidoc.rng schema
> read: (a) dates whose year is given as ?0000?
>> and (b) the date 29 February in
>> the years denoted 0000, -0001, -0004, -0005, etc. (which will be
>> valid if and only if the year number is interpreted as denoting a
>> Gregorian leap year). Inquiries to ancient historians told us they use the
>> dates of the civil calendar, not Gregorian dates (unless for some reason
>> they become interested in when the equinox fell in a given year), so
>> it would surprise me if this affected any real users of XSD or the
>> XSD datatypes.
Live examples for 29 February in BCE dates
and one in CE dates
>> TL;DR: neither XSD 1.0 nor XSD 1.1 nor Relax NG postulates a
>> year 0; the first century of the common era begins in year 1 CE.
> Apologies for the slack phrasing in the original mail; this stuff is hard
> enough to understand without explanations that muff important details.
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> [log in to unmask]