This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
F+O states clearly that processors are only required to support dates with years in the range 0001-9999, yet there are many tests that expect a greater range. Example: prod-CastExpr/CastAs419 [xs:date("-0012-12-03-05:00") cast as xs:date]. I think that such tests should have an alternative result of FODT0001. In the case of the corresponding Castable tests, I think a processor that does not support the required range of values is expected to return false. This means that for a test such as CastableAs419 [xs:date("-0012-12-03-05:00") castable as xs:date], both true and false are acceptable results.
> xs:date("-0012-12-03-05:00") castable as xs:date I don't see how that can return false, because the constructor is called first, raising an exception (FODT0001) before it can test whether the returned date is castable. Unless you mean that a processor may shortcut this expression, when "seeing" that there is an xs:date constructor function, it is always castable as xs:date? Though I think such shortcut is not allowed here, as it would mean that you can get different results.
Added alternative result FODT0001 as suggested in comment #0. Fixes made in test cases in the following test sets: prod-CastExpr prod-CastableExpr fn-year-from-date