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 30041 - [FO31] year-from-date() with negative years
Summary: [FO31] year-from-date() with negative years
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 editorial
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2017-01-04 15:54 UTC by Michael Kay
Modified: 2017-01-10 17:55 UTC (History)
1 user (show)

See Also:


Description Michael Kay 2017-01-04 15:54:27 UTC
I don't think we have 100% clarity of what the expected result of 


should be.

XSD 1.0 says:

'-0001' is the lexical representation of the year 1 Before Common Era (1 BCE, sometimes written "1 BC").... It is the intention of the XML Schema Working Group to allow '0000' as a lexical representation in the dateTime, date, gYear, and gYearMonth datatypes in a subsequent version of this Recommendation. '0000' will be the lexical representation of 1 BCE (which is a leap year), '-0001' will become the lexical representation of 2 BCE (not 1 BCE as in this (1.0) version), '-0002' of 3 BCE, etc.

and this intention was carried out in XSD 1.1

A reader might therefore assume that the result of year-from-date('-0001-06-06')
should be -1 under XSD 1.0 and -2 under XSD 1.1. Indeed, this reader appears to have made this assumption. (Causing test fn-year-from-dateTime-6 to fail in Saxon when XSD 1.1 is enabled).

The F+O spec itself says only "the function returns an xs:integer representing the year component in the local value of $arg. The result may be negative." The definition of "local value" (if it can be called that) in 9.2 does not really address the question. But in the introduction to 9.5 (which defines year-from-date() and year-from-dateTime()) we have an alternative definition:

In all cases the local value (that is, the original value as written, without any timezone adjustment) is used.

which suggests that the intended result is -1.

Generally I think that returning -1 gives fewest surprises and least risk of breaking anything, so I propose that we should clarify, perhaps by means of annotated examples, that this is the expected result. Test case fn-year-from-dateTime-6 is then correct for both XSD versions.
Comment 1 Michael Kay 2017-01-10 17:55:08 UTC
The change was deemed editorial (in that it merely clarifies what the spec already says if you read it carefully enough) and has been applied.