Same goes for "K-SeqExprCast-321"

(In reply to comment #0)
> a
> legal value, because of leap seconds. Compare e.g. "man date".
> 

It's not clear that it can in xquery though, F&O section 10.1.1 says:
Leap seconds are not supported.
although it's not exactly clear what "not supported" means, one interpretation would be that minutes always have 60 seconds.

XQuery 1.0 and XPath 2.0 Functions and Operators, 10.1.1 Limits and Precision reads:

"For a number of the above datatypes [XML Schema Part 2: Datatypes Second Edition] extends the basic [ISO 8601] lexical representations, such as YYYY-MM-DDThh:mm:ss.s for dateTime, by allowing a preceding minus sign, more than four digits to represent the year field — no maximum is specified — and an unlimited number of digits for fractional seconds. Leap seconds are not supported."

Further, see WXS 1.1, 3.3.9.2 Lexical Mappings:

<quote>
timeLexicalRep ::= ((hourFrag ':' minuteFrag ':' secondFrag) | endOfDayFrag) timezoneFrag?
 The timeLexicalRep production is equivalent to this regular expression, once whitespace is removed: 
 (((([01][0-9])|(2[0-3])):([0-5][0-9]):(([0-5][0-9])(\.[0-9]+)?))
   |(24:00:00(\.0+)?))
 (Z|((+|-)(0[0-9]|1[0-4]):[0-5][0-9]))? 
</quote>

WXS 1.0 is rather confused on this area. See section D.1 ISO 8601 Conventions, specifically the last bullet point -- a lot of theoretical reasoning. This is probably why F&O has taken an explicit stance on this, and why WXS 1.1 is clearer.

So, currently I think the correct thing is to resolve this report as INVALID.


Frans

Looking at the spec I agree. Lets see if I stumble across that other test again.

closing.

I might be mistaken, but I'm pretty sure I added support for 62 seconds because of a test in this suite. No idea how to find that one again though ;-)