Re: Timezones and xsd:dateTime/xsd:date

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

Received on Tuesday, 4 September 2007 09:54:45 UTC