Re: Timezones and xsd:dateTime/xsd:date

Eric Prud'hommeaux wrote:
> * Seaborne, Andy <andy.seaborne@hp.com> [2007-09-06 17:53+0100]
>>
>>
>> -------- Original Message --------
>>> From: Eric Prud'hommeaux <mailto:eric@w3.org>
>>> Date: 6 September 2007 17:21
>>>
>>> I read this as saying that in *XQuery*
>>>   "20070906T12:08"^^xsd:dateTime is always >
>>> "20070906T12:07"^^xsd:dateTime (and "20070906"^^xsd:date is always >
>>> "20070906"^^xsd:date)  
>> That is, no timezone info.
>>
>> (Actually in ARQ "20070906"^^xsd:date = "20070906"^^xsd:date :-)
>>
>>> [[
>>> C.2 Dynamic Context Components
>>>
>>> The following table describes how values are assigned to the various
>>> components of the dynamic context. All these components are initialized
>>> by mechanisms defined by the host language. For each component,
>>> "global" indicates that the value of the component remains constant
>>> throughout evaluation of the XPath expression, whereas "dynamic"
>>> indicates that the value of the component can be modified by the
>>> evaluation of subexpressions.      
>>>
>>>                                    Dynamic Context Components
>>> ┌──────────────────┬─────────────────────────────────────────────┐
>>> │      Component   │                                 Scope       │
>>> ├──────────────────┼─────────────────────────────────────────────┤
>>> │Implicit timezone │global; must be initialized by implementation│
>>> └──────────────────┴─────────────────────────────────────────────┘ ]]
>>> --
>>> http://www.w3.org/TR/2007/REC-xpath20-20070123/#id-xp-evaluation-context-components
>>>
>>> - so, there can be only one implicit timezone for the evaluation of a
>>> query. 
>>>
>>> I'd like to follow XQuery; will draft clarifying text after lunch.
>>>
>>> Does that influence your interpretation Andy?
>> I'm following:
>> http://www.w3.org/TR/xmlschema-2/#dateTime-order
>>
>> The text you quote does not change my interpretation of the comparison text - it clarifies what happens in XPath/Xquery 
>>
>> The comparisons both have no timezone so it's case B:
> 
> I see no reason to deviate from XQuery in this regard.

Eric - sorry, I'm now unclear as to your position.

Are you saying that case B does not apply?

> I'd like to
> follow XQuery's lead here and put this clarifying text above 11.3.1:
> 
> [[
> xsd:dateTimes that have no timezone are given an implicit time, as defined by
> <a href="http://www.w3.org/TR/2007/REC-xpath20-20070123/#dt-timezone">XQuery</a>
> ]]
> 
> giving a timezone to all dateTime comparisons. I can't say what an
> extended implementation does with xsd:date, but wouldn't want a test
> case to lock us in to a behavoir that was inconsistent with XQuery
> without discussing the trade-offs.

I am not saying we should deviate from XQuery unnecessarily.  What I think you 
are saying is that the two sections of text disagree - that is, case B can 
never occur. Is that right?

I read case B as admitting that such comparisons can occur.

I can only really make the two sections of text not conflict if I interpret 
the XQuery text as applying a choice over the core definitions in xmlschema-2. 
  But that is pushing the reading a bit too hard.

My preference here is to get a formal comment from somewhere - I'm happy to 
write that email.


Our situation is a little different from XQuery, at least in emphasis, because 
queries may come from a remote client in an unspecified timezone (similarly, 
it can be hard for the client to know the timezone of the server).  This can 
happen with XQuery but the DAWG usage has greater emphasis on query over HTTP. 
  Assigning a default timezone is an option but also a processor might prefer 
not to pick one over the other in order not to misinform - your text seems to 
force a choice.  Hmm - it's a bit worse : client at A could ask a server at B 
to read a graph from C all of which are different timezones.



FWIW I tried the Java standard implementation in Java 5

-------

import javax.xml.datatype.*;

class X
{
    public static void main(String[] argv)
     {
         try {
             DatatypeFactory f = DatatypeFactory.newInstance() ;
             XMLGregorianCalendar c1 = 
f.newXMLGregorianCalendar("2007-09-06T12:00:00") ;
             XMLGregorianCalendar c2 = 
f.newXMLGregorianCalendar("2007-09-06T12:00:00Z") ;
             int x = c1.compare(c2) ;
             System.out.println(x) ;
         } catch (Exception ex)
         { ex.printStackTrace(System.err) ; }
     }
}
-------

which prints 2, which is DatatypeConstants.INDETERMINATE.

javadoc:
http://java.sun.com/j2se/1.5.0/docs/api/
javax.xml.datatype.DatatypeConstants

XMLGregorianCalendar is an abstract class.  When you write this code you find 
that the actaul type is 
com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendar

 Andy

> 
>> [[
>> B. If P and Q either both have a time zone or both do not have a time zone, compare P and Q field by field from the year field down to the second field, and return a result as soon as it can be determined.
>> ]]
>>
>> Cases C and D are the situation where one has a timezone, one does not.
>>
>> (ARQ uses code from Apache Xerces to actually do the comparison - it can return INDETERMINATE).
>>
>>  Andy
>>
>>
>> --------------------------------------------
>>   Hewlett-Packard Limited
>>   Registered Office: Cain Road, Bracknell, Berks RG12 1HN
>>   Registered No: 690597 England
> 

-- 
  Hewlett-Packard Limited
  Registered Office: Cain Road, Bracknell, Berks RG12 1HN
  Registered No: 690597 England

Received on Thursday, 6 September 2007 21:23:43 UTC