This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XML Schema Part 2 contains this Note: <note> The date and time datatypes described in this recommendation were inspired by [ISO 8601]. '0001' is the lexical representation of the year 1 of the Common Era (1 CE, sometimes written "AD 1" or "1 AD"). There is no year 0, and '0000' is not a valid lexical representation. '-0001' is the lexical representation of the year 1 Before Common Era (1 BCE, sometimes written "1 BC"). Those using this (1.0) version of this Recommendation to represent negative years should be aware that the interpretation of lexical representations beginning with a '-' is likely to change in subsequent versions. </note> This is basically an acknowledgement that Schema got it wrong. Normal practice, endorsed by ISO 8601, is that the proleptic gregorian calendar does include a year zero, and that 0, -4, -8 etc are leap years (not -1, -5, -9 etc). So what are we to do about it? Schema can consider changing the rules in a subsequent version, because they're only concerned with validation, and they could introduce some fairly simple version switch to preserve backwards compatible behavior. In our specs, because we are concerned with date computations, I think we need to get this right first time: changing the rules in XPath 3.0 would be very disruptive. A possible option is to say that (for this release) date/time operands and results of arithmetic operations (dt - dt, dt + duration) must not be earlier than 0001-01-01. We could also say explicitly that an implemetation is allowed to support such arithmetic, but if it does so, it must assume the anticipated change in the semantics of the data type, that is, the proleptic gregorian calendar including year zero. Michael Kay
I think that's an excellent suggestion. I've been thinking about this issue this very week, and very gloomy thoughts they were too. Some error codes will be needed (at least two - one for literal dates that are too early, and one for the results of computations). Should there be a system-property() key to test the availability of early dates? My initial tought is that the answer is probably no, as I cannot see how the author of a stylesheet can do much about the situation. My next thought is that a user-friendly diagnostic could be given. Perhaps a more useful system-property() key would be the level of XML Schema that is supported, as this property might not be redundant in XPath 2.1/3.0. I can see a problem for schema-aware processors though - what will happen when you try to validate a stylesheet contain a date in year zero? If it's using XML Schema 1.0, presumably it will fail validation. I guess just this means a schema-aware processor cannot implement this option unless it also has a validating parser with the same behaviour.
You can bash XML Schema if you wish but the fact of the matter is that the version of ISO 8601 that we used for Schema 1.0 did not allow the year zero. This change was made in a subsequent version. My personal preference would be to anticipate the change in Schema and allow the year zero.
Not trying to bash anyone, just trying to decide what to do about the problem. By saying Schema got it wrong, I meant to say it failed to anticipate the direction that ISO 8601 would take. Michael Kay
Actually the date calculations start going pear-shaped if you go before 1753 (when Sweden adopted the Gregorian calendar; England moved in 1752, so that the correct answer for 1752-09-15 - 1752-09-01 is 4. Any other answer is incorrect, and since it is not possible to talk about invalid dates with Schema, you can't mention that 1752-09-10 (for example) does not exist and should be every bit as invalid as allowing a leap second or leap day (29th Feb) when there wasn't one. There was, of course, a 10th of September 1752 in most other European countries, since they had already switched and had their lacunæ -- in some cases there were riots as people felt days were being taken away from them. So you cannot do calculations involving historical dates without knowing, date in which country, and from whose perspective? A spaniard, for example, could write "the 14th of September, which the English called the 2nd of September". When we project the Gregorian calendar backwards boyond the date of its adoption, we get progressively less accurate. It would not be unreasonable to forbid dates earlier than 1754. However, requiring that an implementation check that no intermediate values in a calculation be less than 1754, or less than 1, may be an unreasonable burden. Until such time as Schema supports non-Gregorian calendars, anyone working with historical dates will surely (1) avoid the date/time type, if they know what they are doing, or (2) quickly find life full of surprises... What is the use case for making reference to 0BC an error? Liam
Liam, the xs:date and related types in XML Schema describe dates in the proleptic Gregorian calendar: the fact that this calendar is not/was not used in all parts of the world and at all times in history is an unrelated issue. The problem is that there have traditionally been two definitions of the proleptic Gregorian calendar, one with a year zero and one without: XML Schema chose one and ISO 8601 chose the other. Michael Kay
> The problem is that there have traditionally been two definitions > of the proleptic Gregorian calendar I see, thanks for the clarification! In this case I don't have an opinion except that we obviously need to be aligned with Schema, and it's not clear what the Schema WG will do.. allowing an implementation to raise an error if dates involving years <= 0 may be plausible. I do worry slightly about people writing code to see if one date is before the other by whether the result of a subtraction is negative, but the obvious ways to do that all result in durations.
The WGs decided on 9/27 to close this by making adding the following. 1. Conformant implementations need to support year values greater than 0000. 2. Implementations can chose to support the year value 0000 and negative year values. 3. The results of date/time arithmetic that crosses year 0000 are implementation defined.