Re: [Bug 3027] erroneous date example

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.  ;-)  ]
-- 
Dave Peterson

davep@iit.edu

Received on Tuesday, 3 November 2009 04:29:17 UTC