This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1967 - [F+O] Year Zero
Summary: [F+O] Year Zero
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-09-03 07:33 UTC by Michael Kay
Modified: 2005-09-29 12:57 UTC (History)
0 users

See Also:


Description Michael Kay 2005-09-03 07:33:23 UTC
XML Schema Part 2 contains this 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.

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
Comment 1 Colin Adams 2005-09-03 08:01:55 UTC
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.
Comment 2 Ashok Malhotra 2005-09-03 15:01:31 UTC
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.
Comment 3 Michael Kay 2005-09-03 15:37:08 UTC
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
Comment 4 Liam R E Quin 2005-09-03 17:25:11 UTC
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,
(2) quickly find life full of surprises...

What is the use case for making reference to 0BC an error?

Comment 5 Michael Kay 2005-09-03 17:46:55 UTC
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
Comment 6 Liam R E Quin 2005-09-03 20:54:08 UTC
> 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
Comment 7 Ashok Malhotra 2005-09-27 15:53:52 UTC
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
3. The results of date/time arithmetic that crosses year 0000 are implementation