Re: [Bug 3027] erroneous date example

It does, sort of.  That's kind of what I thought, but as you note, it 
isn't very clear.  And, it is interesting that the description of the 
ordering of dateTime objects speaks of first normalizing the timezone, 
when dateTime objects don't have a timezone, because the value had its 
timezone normalized when the value was determined in the first place.  
So, I can see why Xerces would consider these as two distinct values, 
while others might have considered them as a single value.  If the spec 
was unclear on this, it might be better to say the matter is being 
clarified, rather than implying that this is a certain change in 
behavior.  However, again, I don't think it is a very critical point and 
I'm not going to lose sleep over it.  Just giving my two cents...

Thanks guys,
Kevin

On 11/2/2009 10:28 PM, Dave Peterson wrote:
> At 4:06 PM -0500 2009-11-02, Kevin Braun wrote:
>> 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:
>
>>> 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.
>
> In 1.0, the normalization to UTC occurs during the calculation of the
> value when given the lexical representation.  (That's not exactly how
> it's described in 1.0, but that's the effect.  I wish 1.0 had been
> clearer.)  This makes the "two" time values identical.  Given that
> we are then looking at the same value twice, adding the same arbitrary
> date makes the resulting dateTime value ("values") identical (to itself)
> as well.
>
> Hope this helps.
>
> [Please forgive the quotes and such; I've been balled out on occasion for
> talking about two values when in fact they are identical and so I'm 
> really
> just talking about one value.  ;-)  ]

Received on Tuesday, 3 November 2009 15:06:31 UTC