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.10 date This section states, "2000-12-12+13:00 = 2000-12-13-11:00 (whereas under 1.0, as just stated, 2000-12-12+13:00 = 2000-12-12-11:00)". I believe that the initial "=" should be "!=". This comment has been entered on behalf of the XML Query and XSL WGs.
(In reply to comment #0) > This section states, "2000-12-12+13:00 = 2000-12-13-11:00 (whereas under 1.0, > as just stated, 2000-12-12+13:00 = 2000-12-12-11:00)". I believe that the > initial "=" should be "!=". As the WG was about to accept this recommendation, we realized that the words are correct as stated. Note that in the first equation, true in 1.1, the date on the LHS is 12 Dec and on the RHS it is 13 Dec. OTOH, in the equation in parens, true in 1.0, the dates on both sides are 12 Dec. The WG directed the editors to provide a Note more clearly explaining what is being pointed out in this comparison.
(In reply to comment #1) > As the WG was about to accept this recommendation, we realized that the words > are correct as stated. > The WG directed the editors to provide a Note more clearly explaining what is > being pointed out in this comparison. The Note or more explanatory in-line text will be provided. But in a msg to the Schema WG, Sandy pointed out that nonetheless the equality was not correct. Correct candidate equalities are either 2000-12-13+13:00 = 2000-12-12+11:00 and 2000-12-12+13:00 = 2000-12-11+11:00; one or the other will likely be used.
(In reply to comment #2) > The Note or more explanatory in-line text will be provided. But in a msg to > the Schema WG, Sandy pointed out that nonetheless the equality was not correct. > Correct candidate equalities are either 2000-12-13+13:00 = 2000-12-12+11:00 > and 2000-12-12+13:00 = 2000-12-11+11:00; one or the other will likely be used. &%#%&^ typo: s/+11:00/-11:00/g in this para.
(In reply to comment #3) > > The Note or more explanatory in-line text will be provided. But in a msg to > > the Schema WG, Sandy pointed out that nonetheless the equality was not correct. > > Correct candidate equalities are either 2000-12-13+13:00 = 2000-12-12+11:00 > > and 2000-12-12+13:00 = 2000-12-11+11:00; one or the other will likely be used. > > &%#%&^ typo: s/+11:00/-11:00/g in this para. I propose the following rewording of the two bullets: A day is a calendar (or "local time") day in each timezone, including the timezones outside of +12:00 through -11:59 inclusive: 2000-12-12+13:00 < 2000-12-12+11:00 (just as 2000-12-12+12:00 has always been less than 2000-12-12+11:00, but in version 1.0 2000-12-12+13:00 > 2000-12-12+11:00 , since 2000-12-12+13:00 = 2000-12-12-11:00 because 2000-12-12+13:00's "recoverable timezone" was ?11:00) Similarly: 2000-12-12+13:00 = 2000-12-11-11:00 (whereas under 1.0, as just stated, 2000-12-12+13:00 = 2000-12-12?11:00) I hope that the explicit statement of the 1.0 inequality in the first bullet will make the point of the second bullet more obvious.
> ... but in version 1.0 > 2000-12-12+13:00 > 2000-12-12+11:00 , since > 2000-12-12+13:00 = 2000-12-12-11:00 because 2000-12-12+13:00's > "recoverable timezone" was -11:00) In 1.0, the canonical rep for "date" is the "mid point date + recoverable timezone". For "2000-12-12+13:00", the mid point is 2000-12-12T12:00:00+13:00 = 2000-12-11T23:00:00Z So the canonical is "2000-12-11-11:00" So 2000-12-12+13:00 is 1 day earlier than 2000-12-12-11:00. This convinced me that 1.0 and 1.1 behave in the same way and we should simply remove the remarks about 1.0.
(In reply to comment #5) > This convinced me that 1.0 and 1.1 behave in the same way and we should simply > remove the remarks about 1.0. I am now convinced that two dates are equal under 1.0 if and only if they are equal under 1.1. The only difference is that under 1.1 two dates may be equal but not identical. It may still be appropriate to have an example of equal-but-not-identical date values, with prose indicating that that is the only way they can differ between versions.
The WG decided on 30 Mar to replace the paragraph beginning "Examples that show the difference..." with: date values in different timezones that were identical in the 1.0 version of this specification, such as 2000-12-12+13:00 and 200-12-11-11:00, are in this version of this specification equal (because they begin at the same moment on the time line) but are not identical (because they have and retain different timezones).
The change proposed above was approved by the WG on 30 March 2007 at its face to face meeting in Cambridge. It is now reflected in the status quo version of the Datatypes spec. Accordingly, I am setting the disposition of this issue to RESOLVED / FIXED. If the originator of the issue would examine the change and let us know whether it satisfactorily resolves the problem or not, we'd be grateful. To signal that the resolution is acceptable, change the status of the issue to CLOSED. Otherwise, to signal that it's NOT acceptable, change the status to REOPENED (and tell us what's wrong). If we don't hear from you in the next three weeks, we'll assume that silence betokens consent, and close the issue ourselves.
Looking at the Apr 2009 recommendation, it looks like the proposed fix never made it into the recommendation. The text still reads thus: Examples that show the difference from version 1.0 (see Lexical Mapping (§3.3.10.2) for the notations): * A day is a calendar (or "local time") day offset from ·UTC· by the appropriate interval; this is now true for all ·day· values, including those with time zone offsets outside the range +12:00 through -11:59 inclusive: 2000-12-12+13:00 < 2000-12-12+11:00 (just as 2000-12-12+12:00 has always been less than 2000-12-12+11:00, but in version 1.0 2000-12-12+13:00 > 2000-12-12+11:00 , since 2000-12-12+13:00's "recoverable time zone offset" was −11:00) * Similarly: 2000-12-12+13:00 = 2000-12-13−11:00 (whereas under 1.0, as just stated, 2000-12-12+13:00 = 2000-12-12−11:00)
FYI, I just read the following in the *time* section: Date values with different time zone offsets that were identical in the 1.0 version of this specification, such as 2000-12-12+13:00 and 2000-12-11−11:00, are in this version of this specification equal (because they begin at the same moment on the time line) but are not identical (because they have and retain different time zone offsets). Perhaps the fix was applied to the wrong section.
(In reply to comment #9) > Looking at the Apr 2009 recommendation, it looks like the proposed fix never > made it into the recommendation. (In reply to comment #10) > FYI, I just read the following in the *time* section: > > Date values with different time zone offsets that were identical in the 1.0 > version of this specification, such as 2000-12-12+13:00 and > 2000-12-11−11:00, are in this version of this specification equal > (because they begin at the same moment on the time line) but are not identical > (because they have and retain different time zone offsets). > > Perhaps the fix was applied to the wrong section. Well, I've spent more time than it's probably worth trying to track down the historical documentation of what happened, and I can't find it. I do recall several quite long discussions among some editors as to whether the original problem was indeed a problem, that there was actually a related problem that should be fixed. I believe that fix was erroneously put into the master in the wrong section ("time" instead of "date"). Some time later (and after the publication of the CR), one of the editors noticed that the Note now in the "time" section) talked about dates rather than times. A bug report was filed, and in the current status quo, said note talks about times and has time examples. Anyone working from the current CR version would not know about that. In any case, I suspect that the original note should be put into the "date" section (but I hope that will be rechecked--in any case, I believe the inequalities quoted are not correct and should be changed if not replaced by the note). We should probably also check to make sure that the now-status-quo note in "time" is really appropriate. :-(
A wording proposal intended to resolve this issue is now on the server at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b3027b.html The note originally intended for the 'date' section has now, at last, found its proper home. And the note in the 'time' section, which puzzled the WG and led to some revisions which attempted, with modest success, to make it relate coherently to time values instead of dates, has been replaced. The new words read: Some pairs of time literals which in the 1.0 version of this specification denoted the same value now (in this version) denote distinct values instead, because values now include time zone offset information. Some such pairs, such as '05:00:00-03:00' and '10:00:00+02:00', now denote equal though distinct values (because they identify the same points on the time line); others, such as '23:00:00-03:00' and '02:00:00Z', now denote unequal values (23:00:00−03:00 > 02:00:00Z because 23:00:00−03:00 on any given day is equal to 02:00:00Z on the next day).
Regarding the part that reads "others, such as '23:00:00-03:00' and '02:00:00Z', now denote unequal values": it is not clear to me that these would have been considered equal under 1.0. I say this because XML Schema 1.0, Part 2, section 3.2.8 "time" says "The order relation on time values is the Order relation on dateTime (§3.2.7.4) using an arbitrary date." This, with the above statement, seems to imply that under 1.0 (adding an arbitrary date), '2009-11-02T23:00:00-03:00' denoted a value equal to '2009-11-02T02:00:00Z', which I don't think was the case. If the literal '23:00:00-03:00' were mapped to the value 02:00:00, then I could see how it would have been considered equal to '02:00:00Z' under 1.0, but I don't see where that is called for. Additionally, the rules in 3.2.7.4 include a step for timezone normalization, which is meaningless if the timezone has already been lost. Also, Xerces tells me the following instance is not valid for the following schema, which tells me at least Xerces considered these two times not equal. <root>23:00:00-03:00</root> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="root"> <xs:simpleType> <xs:restriction base="xs:time"> <xs:enumeration value="02:00:00Z"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:schema> Maybe some processors considered these times equal while others didn't?
The change proposal mentioned in comment 12 was approved by the WG during its call of 13 November; it has now been integrated into the status-quo documents on the server. Accordingly, I'm marking this issue 'resolved'. Both Andrew Eisenberg and Kevin Braun have raised (or re-raised) this issue; I ask both of them, therefore, to confirm in a comment here that they are satisfied with the disposition of the issue; the second one to respond should feel free to close the issue. If either of you is dissatisfied, please say so and explain what changes would satisfy your concerns. If we don't hear from you in the next two weeks, we will assume that you are both content with the disposition of the issue.
I'm fine with the change. For posterity, here's a link to some follow-up discussion that took place in response to comment #9: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2009OctDec/0129.html
oops, the above should be "in response to comment #13"
The WG reported this bug as FIXED on 2009-11-30. We are closing this bug as requiring no futher work. If there are issues remaining, you can reopen this bug and enter a comment to indicate the problem. Thanks very much for the feedback.