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 3377 - [F+O] About op:time-equal using xs:dateTime
Summary: [F+O] About op:time-equal using xs:dateTime
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL: http://www.w3.org/TR/xquery-operators...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-21 12:50 UTC by atsushi.ohtake
Modified: 2006-06-23 13:12 UTC (History)
0 users

See Also:


Attachments

Description atsushi.ohtake 2006-06-21 12:50:11 UTC
Confirmation about example of 10.4.12 op:time-equal.

Why below example return true ?
op:time-equal(xs:time("24:00:00+01:00"), xs:time("00:00:00+01:00")) returns true.

According to spec of this function, this example normalize to 
1972-12-31T23:00:00Z and 1972-12-30T23:00:00Z, so it should return false.

And section of "10.2 Date/time datatype values" says 
"For xs:dateTime, a time component "24:00:00" translates to "00:00:00" of the following day.", I think.

Regards,
Atsushi Ohtake
Hitachi, Ltd.
Comment 1 Michael Kay 2006-06-21 13:37:45 UTC
This example was added to the spec deliberately because it is not the result you might expect. For xs:dateTime values, it's true that a time of 24:00:00 is equivalent to 00:00:00 on the following day. But for xs:time, the normalization from 24:00:00 to 00:00:00 happens before the time is converted into a dateTime for the purpose of the equality comparison. For xs:time, any operation on 24:00:00 produces the same result as the same operation on 00:00:00 because these are two different lexical representations of the same value.

Michael Kay
(personal response)
Comment 2 atsushi.ohtake 2006-06-22 11:01:40 UTC
Thanks for your reply, Michael.

If I am according to your reply, we need more examples especially for 24:00:00 and 00:00:00.

And my understand is below that is according to your reply.

Assume that the dynamic context provides an implicit timezone value of -05:00.
?Eop:time-equal(xs:time("23:00:00+00:00"), xs:time("00:00:00-01:00")) returns false.
?Eop:time-equal(xs:time("00:00:00"), xs:time("00:00:00-01:00")) returns true.
?Eop:time-equal(xs:time("00:00:00+01:00"), xs:time("24:00:00+05:00")) returns true.
?Eop:time-equal(xs:time("00:00:00"), xs:time("24:00:00+09:00")) returns true.

My understand is correct ?
Comment 3 Michael Kay 2006-06-23 13:12:21 UTC
The Working Group discussed your comment and agreed it would be useful to add some editorial text to the example explaining why the result is what it is, along the lines of the explanation in comment #1. (There is a detailed suggestion in the meeting minutes - member only).

Concerning your supplementary questions, since these are not comments on the specification, it might be better to raise them on a forum such as query-talk at xquery.com. I don't think your calculations are correct, as it happens:

* xs:time("00:00:00") and xs:time("00:00:00-01:00") will only be equal if the implicit timezone is -01:00

* xs:time("00:00:00+01:00") and xs:time("24:00:00+05:00") will never be equal

* xs:time("00:00:00") and xs:time("24:00:00+09:00") will be equal only if the implicit timezone is +09:00.

But the part of the rule that's relevant to this comment is that in any comparison of two xs:time values, 24:00:00 gives the same result as 00:00:00 (in the same timezone, or in no timezone if there is none).

I'm marking this as FIXED and CLOSED on the basis that we decided to make the example more clear. If you are not happy with this closure, please reopen the bug. If you want further help in understanding the specification, I would suggest you use a different forum.

Michael Kay
for the XSL and XQuery Working Groups