This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
3.3.7 dateTime [1] says "Equality and order are as prescribed in The Seven-property Model (§D.2.1). dateTime values are ordered by their ·timeOnTimeline· value." AIUI, the timeOnTimeline value is essentially the number of seconds since 0001-01-01T00:00:00Z. This sentence seems to say that e.g. 2013-09-25T15:00:00-06:00, 2013-09-25T13:00:00-08:00 and 2013-09-25T21:00:00Z are "equal" – all three result in the same timeOnTimeline value of 63519282000. The same section says also "Note: Order and equality are essentially the same for dateTime in this version of this specification as they were in version 1.0. However, since values now distinguish time zone offsets, equal values with different ·timezoneOffset·s are not identical, and values with extreme ·timezoneOffset·s may no longer be equal to any value with a smaller ·timezoneOffset·." I'm unclear about what this means. The last part of this paragraph says that "values with extreme ·timezoneOffset·s may no longer be equal to any value with a smaller ·timezoneOffset·." Here the term "equal" is used. This fragment seems to contradict the earlier statement that equality is determined by the timeOnTimeline value. AIUI, it is always possible to create a value with a smaller timezoneOffset value that is "equal" (in the timeOnTimeline sense) to a value with an "extreme timezoneOffset value". Can you please clarify? What are "extreme" timezoneOffsets? What concept of "equal" is used in this fragment? Can you give an example of such a value that is not equal to any value with a smaller timezoneOffset? Thank you. ---- [1] http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#dateTime
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)
(In reply to C. M. Sperberg-McQueen from comment #1) Thank you very much; this all makes sense. (Especially the suggestion that this note may apply to subtypes like xs:time was helpful.) While the status of this ticket would be "resolved" for me, I don't think it is for the document, so I leave it as it is and let the editors of the document handle this.