W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2009

Re: [Bug 3027] erroneous date example

From: Kevin Braun <kbraun@obj-sys.com>
Date: Mon, 02 Nov 2009 16:06:45 -0500
Message-ID: <4AEF49E5.1070408@obj-sys.com>
To: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
CC: www-xml-schema-comments@w3.org
I'm not terribly worried about it, but I don't see that there is a 
change here between 1.0 and 1.1.  Xerces says the two times are not 
equal.  I can't figure out how they would be equal.  Section 3.2.8, 
which gives the algorithm for the ordering, doesn't mention applying an 
arbitrary date.  It probably doesn't matter very much if this statement 
remains as-is, even if it is wrong in implying that 1.0 treats 
'23:00:00-03:00' and '02:00:00Z' as equal, but as far as I can make out, 
it is in fact wrong.  At the same time, I can see how different 
processors might have done different things here, because the 
relationship between lexical and actual value is a little unclear.

On 11/2/2009 3:53 PM, C. M. Sperberg-McQueen wrote:
>
> On 2 Nov 2009, at 13:30 , bugzilla@wiggum.w3.org wrote:
>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3027
>>
>>
>> --- Comment #13 from Kevin Braun <kbraun@obj-sys.com>  2009-11-02 
>> 20:30:37 ---
>> 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.
>
> 1.0 operationalized the time comparison by (a) normalizing to
> UTC, (b) supplying an arbitrary date (e.g. 31 December 1971), and
> (c) comparing the resulting times.
>
> 1.1 changes that, in response to what has been called the Japanese
> shop hour or Tokyo-Chicago telcon problem, by reversing the order
> of steps (a) and (b).  If you supply the date first, and then
> normalize to UTC, the result is, as you suggest, different.
>
> I will seek out chapter and verse if necessary, but I don't have
> time to do that at the moment.  My confidence that 1.0 behaved
> as described is due in part to clear memories of the WG meetings
> in which we discussed the discrepancies between XSD's treatment of
> date and time related types and their treatment in XPath 2.0 and
> related specs, and of the discussions of the Japanese store-hour
> and Tokyo-Chicago telcon issues.
>
Received on Monday, 2 November 2009 21:08:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:13:19 GMT