This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hello, Currently the spec at http://www.w3.org/TR/2007/REC-xpath-functions-20070123/ contains the following notes: *** quote *** 10.4.12 op:time-equal [...] This function backs up the "eq", "ne", "le" and "ge" operators on xs:time values. 10.4.13 op:time-less-than [...] This function backs up the "lt" and "le" operators on xs:time values. 10.4.14 op:time-greater-than [...] This function backs up the "gt" and "ge" operators on xs:time values. *** end quote *** However, according to http://www.w3.org/TR/2007/REC-xquery-20070123/#mapping the operators are mapped thus: A eq B -> op:time-equal(A, B) A ne B -> fn:not(op:time-equal(A, B)) A gt B -> op:time-greater-than(A, B) A lt B -> op:time-less-than(A, B) A ge B -> fn:not(op:time-less-than(A, B)) A le B -> fn:not(op:time-greater-than(A, B)) The mapping would suggest that op:time-equal backs up "eq" and "ne"; op:time-greater-than backs up "gt" and "le"; and op:time-less-than backs up "lt" and "ge". However I'm not sure the mapping in the XQuery spec is what is intended: Using that mapping, two xs:time values that should be incomparable because of time-zone differences would return false from the "eq", "gt" and "lt" operators, but true for "ne" (correct), "ge" and "le"—the latter two would seem wrong. To reflect incomparable values, the "le" and "ge" operators should map to “op:time-less-than(A, B) or op:time-equal(A, B)” and “op:time-greater-than(A, B) or op:time-equal(A, B)”, respectively, similar to how numeric values are compared. I think something similar should apply to xs:dateTime, but I haven't checked thoroughly that case yet.
>The mapping would suggest that op:time-equal backs up "eq" and "ne"; op:time-greater-than backs up "gt" and "le"; and op:time-less-than backs up "lt" and "ge". Yes, I think that's correct, and the "backs up" statements should be corrected. >However I'm not sure the mapping in the XQuery spec is what is intended: Using that mapping, two xs:time values that should be incomparable All xs:time values are comparable using these operators. Timezone differences are handled by applying the implicit timezone. I'm not absolutely sure whether the two possible definitions of the operators are equivalent, for example whether not($s lt $t) is always equivalent to ($s eq $t or $s gt $t), but to avoid depending on this we should be consistent in how it's defined.
(In reply to comment #1) > >However I'm not sure the mapping in the XQuery spec is what is intended: Using > that mapping, two xs:time values that should be incomparable > > All xs:time values are comparable using these operators. Timezone differences > are handled by applying the implicit timezone. You're right, I'm sorry. This part of my report should be disregarded. I think I had mixed up the XQuery and XML Schema specs. > I'm not absolutely sure whether the two possible definitions of the operators > are equivalent, for example whether not($s lt $t) is always equivalent to ($s > eq $t or $s gt $t), but to avoid depending on this we should be consistent in > how it's defined. They are equivalent whenever the operators create a total order. IIRC, xs:times with and without timezones are not totally ordered in the sense of XML Schema, but they are totally ordered with respect to the XQuery gt/lt/eq operators. The implicit timezone bridges the two “ordering domains”. That's what confused my original report. Should the original description be edited, or are these comments enough?
Agreed that we will change the "backs up" sentences to match what's in the table. This is editorial so we are marking it FIXED.
I discovered that this change had not been applied in the 3.0 specifications, and I have now applied it (affects the less-than and greater-than functions for date, time, and dateTime). I have also added this to the list of candidate errata for the 1.0/2.0 specification. I am now taking the opportunity to mark the bug closed, so it no longer comes up as needing attention.