This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The way that op:time-equal is currently defined leads to some unintuitive results. For example I would have expected that adjusting the timezone of a time would not affect the comparison, since it still represents the same point in time. However consider the following query: let $time := xs:time("23:00:00Z") return adjust-time-to-timezone($time, xs:dayTimeDuration("PT2H")) = adjust-time-to-timezone($time, xs:dayTimeDuration("-PT2H")) The two arguments yield the times 01:00:00+02:00 and 21:00:00-02:00. Although these times refer to the same point in time, after they are converted to xs:dateTimes their values differ by 24 hours, and so the result is false. This seems very counter-intuitive. Perhaps the normalization to the context timezone should occur before conversion to xs:dateTime; or at least this case should be mentioned in the specification.
I think the problem is that while it makes sense intuitively for equality-matching of xs:time values to be "cyclic" in the way described, it does not make sense for ordering to be cyclic; and if "=" is cyclic while ">" is not, then it becomes difficult to ensure invariants like a=b == a>=b and a<=b. Perhaps the mistake was in making xs:time ordered.
The Working Group looked at this on Oct 7th 2008. The design is as it is after a lot of WG debate; we know that some of the behaviour of dates and times is non-intuitive, but it was the best we could do at the time and it is not obvious that any minor changes will make matters better rather than worse. We are therefore resolveing this as "works for me". Oliver, To signal your acceptance of this decision, we would be grateful if you could mark the bug as closed. Michael Kay for the joint working groups
I agree that at this stage in the game it is not worth making (potentially breaking) changes like this, although I still stand by my original statement that the specification would benefit from an additional example for time-equal illustrating this particular subtlety.
Reopening, because I note there is a very trivial error in the explanation of one of the examples in 10.4.12.1: "These normalize to 1972-12-30T23:00:00Z and 1972-12-31T23:00:00" should read "These normalize to 1972-12-30T23:00:00Z and 1972-12-31T23:00:00Z" In fixing that, I guess I can add another example at the same time; though I don't think any number of examples are going to prevent timezones causing surprises.
Also note that this situation means that two xs:time values that have the same canonical representation* can be not equal, which is inconsistent with what a canonical representation should mean**. *: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#time-canonical-repr **: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#canonical-lexical-representation
>two xs:time values that have the same canonical representation* can be not equal Sorry, I don't understand how that can happen. Can you explain please?
(In reply to comment #6) > >two xs:time values that have the same canonical representation* can > > be not equal > Sorry, I don't understand how that can happen. Can you explain please? According to the first example at http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#func-time-equals-examples *** quote *** op:time-equal(xs:time("08:00:00+09:00"), xs:time("17:00:00-06:00")) returns false. The xs:dateTimes calculated using the reference date components are 1972-12-31T08:00:00+09:00 and 1972-12-31T17:00:00-06:00. These normalize to 1972-12-30T23:00:00Z and 1972-12-31T23:00:00. *** end quote *** However, according to http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#time-canonical-repr *** quote *** The canonical representation for time is defined by prohibiting certain options from the Lexical representation (§3.2.8.1). Specifically, either the time zone must be omitted or, if present, the time zone must be Coordinated Universal Time (UTC) indicated by a "Z". Additionally, the canonical representation for midnight is 00:00:00. *** end quote *** This means that an xs:time value with a timezone must be adjusted to UTC. The spec does not specify exactly how this is done, but http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#time-lexical-repr says *** quote *** The lexical representation for time is the left truncated lexical representation for dateTime: hh:mm:ss.sss with optional following time zone indicator. For example, to indicate 1:20 pm for Eastern Standard Time which is 5 hours behind Coordinated Universal Time (UTC), one would write: 13:20:00-05:00. See also ISO 8601 Date and Time Formats (§D). *** end quote *** The latter implies that the value for the "hh" field can only be between 00 and 24 (see http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime-lexical-representation — the sixth bullet point); also, time values cannot be negative. This suggests that when adjusting a timezoned xs:time value to UTC, it wraps around to remain between “00:00:00” and “23:59:59.(9)” This means that the canonical representations for the values in the example (first quote above), xs:time("08:00:00+09:00") and xs:time("17:00:00-06:00"), must both be “23:00:00Z” (8-9 = -1; -1 mod 24 = 23; 17+6 = 23). Yet the example claims that they are not op:time-equal.
The XDM model explicitly states that for the date/time types, timezone distinctions are retained in the value space. See section 3.3.2 in the Data Model spec, and section 10.2 in Functions and Operators. This is a conscious departure from the definition of the types in XSD 1.0, and is consistent with the way these types are described in XSD 1.1. Using the XSD 1.0 definition would have been unworkable; it would have meant that an identity transformation lost all timezone information.
(In reply to comment #8) > The XDM model explicitly states that for the date/time types, timezone > distinctions are retained in the value space. See section 3.3.2 in the Data > Model spec, and section 10.2 in Functions and Operators. This is a conscious > departure from the definition of the types in XSD 1.0, and is consistent with > the way these types are described in XSD 1.1. Well, OK, but this still means that “two xs:time values that have the same canonical representation can be not equal”. This may well be intentional*, but I think it should be at least noted in the definition of op-time-equal. Note that the XQuery 1.0 spec does not mention XSD 1.1. (*: In fact, I can find no use of the canonical form for xs:time in the XQuery/XPath specs, including the F&O spec, so this is an external rather than an internal inconsistency.)
I've recharacterized this bug as Minor on the grounds that it was reopened because of "a very trivial error in the explanation of one of the examples in 10.4.12.1", as well as a suggestion in http://www.w3.org/Bugs/Public/show_bug.cgi?id=5939#c9 that a note might be helpful.
The "very trivial error" mentioned in comment #10 was still present in the 3.0 draft, but I have now corrected it. I have also added the correction to the list of candidate errata for the 1.0/2.0 specification. I am therefore now marking the bug as closed.