- From: <bugzilla@jessica.w3.org>
- Date: Wed, 09 Oct 2013 19:29:13 +0000
- To: www-xml-schema-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23473 --- Comment #1 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> --- I believe that you are right that the three examples you cite are equal, for the reason you give. They denote the same moment in the timeline of the earth. They are not, however, identical in XSD 1.1. (They were identical in XSD 1.0, but the working groups responsible for XSLT and XQuery refused to accept that decision and defined the time zone as being an intrinsic part of the value, in order to distinguish cases like these from each other. To align with the XSLT and XQuery specifications, XSD 1.1 changed its definition of the value spaces for the relevant types.) By "extreme" time zone offsets, the note means time zone offsets near the minimum of maximum allowed values. (Specifically, I believe the phenomena the note is trying to refer to appear with time zone offsets whose difference from UTC is 720 minutes or greater.) I believe the concept of equality it is talking about is the one defined elsewhere (that is: I do not think "equal" is a typographic error for "identical", nor do I think that some other notion is involved). The note is indeed a bit puzzling. The record shows it was part of a change proposal adopted by the XML Schema WG on 11 February 2005 [1]; the minutes [2] do not record any particular discussion of the note. I suspect that when the note was originally drafted, the drafter was thinking of all of the date/time datatypes together, and not specifically of xs:dateTime; for the type xs:time, for example, the value xs:time('23:59:00-14:00') is not (as far as I can see at the moment) equal to any other xs:time value. This is a consequence of the way in which time values are augmented in order to calculate timeOnTimeline values. Since dateTime values are not augmented in this way, I do not see any way for a value of xs:dateTime to fail to be equal to other dateTime values. (But the history of the working group's discussions in this area provides a sobering warning against assuming that there are none, because we can't think of any at the moment.) I am inclined to think that the note is misleading to suggest that dateTime values with time zone offsets exceeding 720 minutes may be unequal to any values with lower time zone offsets; this is true for some date/time types, but (it seems to me today) not to dateTime. In a perfect world, the responsible WG would issue an editorial correction. But in view of the fact that the note is not strictly speaking in error (it doesn't say that some dateTime values are not equal to any others, only that there may be such), that it's non-normative (being a note), that the area is extremely error prone and all changes must be approached with extreme caution, and that the responsible WG has very limited resources, I expect it's unlikely that this mistake (if I am right that it is one) will be fixed soon. [1] https://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.rq122.200502.html (member-only link) [2] https://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2005Feb/0051.html (member-only link) -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 9 October 2013 19:29:15 UTC