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

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)

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

* Seaborne, Andy <andy.seaborne@hp.com> [2007-09-04 10:54+0100]
>
>
>
> Lee Feigenbaum wrote:
>> Seaborne, Andy wrote:
>>>
>>> Lee Feigenbaum wrote:
>>> ...
>>>> + comparing timezones vs. non-timezoned values in open-world/data-n 
>>>> tests (issue for EricP / AndyS ?)
>>> I think the comment has a point - there is something untoward here about 
>>> comparing dateTime or date with no time zone with one that does have a 
>>> time zone.  (I would really like Eric to confirm or refute this in case 
>>> I've misread or not fount the right place to read in the XSF/F&O docs.)
>>>
>>> The solution is change the tests.  If we want to be in picky mode, its 
>>> the result that change,; if we want to be relaxed, change the data so 
>>> comparisons are more than 14 hours apart.
>> I like the latter solution.
>> If someone can check it in to CVS and mark the test as not approved, we 
>> can approve it on Tuesday.
>> Lee
>>> ...
>>>> Lee
>>>     Andy
>>>
>
> Looking further into this ... I think test date-1 is wrong and needs fixing 
> but date-2 does have the right answers, although when written, for the 
> wrong reasons.
>
>
> The date-01 test [1]:
>
> The filter is
>   FILTER ( ?v = "2006-08-23"^^xsd:date )
>
> It was:
>
> ------------------------------------------------------
> | x                   | v                            |
> ======================================================
> | <http://example/d3> | "2006-08-23+00:00"^^xsd:date |
> | <http://example/d2> | "2006-08-23Z"^^xsd:date      |
> | <http://example/d1> | "2006-08-23"^^xsd:date       |
> ------------------------------------------------------
>
> but "2006-08-23+00:00"^^xsd:date is not comparable with 
> "2006-08-23"^^xsd:date (full details at [2]).
>
> I have fixed the results, and commented out the approval in the manifest 
> temporarily.
>
>
> The date-2 test has at it's heart the filter:
>
>   FILTER ( ?v != "2006-08-23"^^xsd:date )
>
> but != should be an error when ?v is a date that can not compared with 
> "2006-08-23"^^xsd:date
>
> So this happens to be the same as before - the dates that were "!=" are 
> still the ones that are known to be "!=".
>
> For example: When ?v is "2006-08-23+00:00"^^xsd:date (it has a timezone), 
> xsd:date tests work on the initial point of the date but that has an 
> indeterminate relationship to an un-timezoned date (less than 14 hours 
> difference - the full algorithm is [2]).
>
> In a filter "not comparable" is an error and the EBV is false.  So you get 
> the same answers (for different reasons).
>
>
> Given that, fixing one results is less of a change than data change 
> affecting 3 tests.
>
>  Andy
>
>
>
> [1] http://www.w3.org/2001/sw/DataAccess/tests/data-r2/open-world/date-1.rq
> [2] http://www.w3.org/TR/xmlschema-2/#dateTime-order
>     "3.2.7.4 Order relation on dateTime"
>        in "XML Schema Part 2: Datatypes Second Edition"
>
> -- 
> 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.