Re: Re: Timezones and xsd:dateTime/xsd:date

* Seaborne, Andy <andy.seaborne@hp.com> [2007-09-06 22:23+0100]
>
>
> 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 :-)

not in my implementation; the parser takes a half day to get from one
token to the next.
no, wait, i'm arguing that that doesn't matter.

>>>
>>>> [[
>>>> 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?

Yeah, I believe that only case A arrises in XQuery.

>> 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 think the lower-level spec admits the indeterminacy of timezone-less
dates/times but that the spec that uses it, XQuery, ensures that there
is always a timezone. Looking up the spec stack (XQuery -> XML Schema):

[[
• [Definition: Implicit timezone. This is the timezone to be used when
  a date, time, or dateTime value that does not have a timezone is
  used in a comparison or arithmetic operation. The implicit timezone
  is an implementation-defined value of type xs:dayTimeDuration. See
  [XML Schema] for the range of legal values of a timezone.]
]]
-- http://www.w3.org/TR/2007/REC-xquery-20070123/#dt-timezone

[[
...
[XML Schema Part 2: Datatypes Second Edition] also states that the
order relation on date and time datatypes is not a total order but a
partial order because these datatypes may or may not have a
timezone. This is handled as follows. If either operand to a
comparison function on date or time values does not have an (explicit)
timezone then, for the purpose of the operation, an implicit timezone,
provided by the dynamic context Section C.2 Dynamic Context
ComponentsXP, is assumed to be present as part of the value. This
creates a total order for all date and time values.

...
An xs:dateTime can be considered to consist of seven components: year,
month, day, hour, minute, second and timezone. For xs:dateTime six
components: year, month, day, hour, minute and second are required and
timezone is optional. For other date/time values, of the first six
components, some are required and others must be absent or
missing. Timezone is always optional.
...
]]
-- http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#comp.duration.datetime

[[
B. If P and Q either both have a time zone or both do not have a time
zone, ...
C. C.Otherwise, if P contains a time zone and Q does not, compare as
follows...
D. Otherwise, if P does not contain a time zone and Q does, compare as
follows...
]]
-- http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime-order

> 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.

Philippe, Michael and I are confident that that the above maze is
definitive for dateTime. xsd:date extensions may need to return an
error there, but none of the error-handling wording in 11 is specific
to type error. A new row in the mapping table will suffice for adding
xsd:date, regardless of the errors it may return.

> 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

-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.