W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2007

Re: Timezones and xsd:dateTime/xsd:date

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 10 Sep 2007 21:50:59 +0100
Message-ID: <46E5AE33.5030403@hp.com>
To: Eric Prud'hommeaux <eric@w3.org>
Cc: Lee Feigenbaum <lee@thefigtrees.net>, RDF Data Access Working Group <public-rdf-dawg@w3.org>

Eric Prud'hommeaux wrote:
> 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.

xsd:dateTime is, for the SPARQL Query spec, the important case.  Let me gather
the details together - it's a bit long - sorry.

== Summary

I can't find a chain from rq25 to the XQuery text.  That seems to define what
an XQuery processor does.  I can find text in more than one place that
suggests the opposite for SPARQL.

It is a bit messy though.

== RDF and datatypes

When we use a datatype of xsd:dateTime, it means, from RDF Semantics
The datatype map which also contains the set of all pairs of the form
<http://www.w3.org/2001/XMLSchema#sss, sss>, where sss is a built-in datatype
named sss in XML Schema Part 2: Datatypes [XML-SCHEMA2] and listed in the
following table, is referred to here as XSD.

which directly names xsd:dateTime and links to:

RDF Concepts agrees and states its the abstraction that matters:
The datatype abstraction used in RDF is compatible with the abstraction used
in XML Schema Part 2: Datatypes [XML-SCHEMA2].

So it's the XML Schema definition that is the right one.  I can't find a route
from XML Schema to text saying there is a default time zone.  In fact, it says
that some comparisons are indeterminate implying there is no such concept for
XML Schema.

What's more, RDF defines a datatypes as having a mapping from lexical to value
space.  Concepts says

Each member of the lexical space is paired with (maps to) exactly one member
of the value space.
Different choices of default time zone would change the pairing and there
would not be exactly one member of the value space.

== rq25 operator mapping

If we look at "=" for xsd:dateTime

A = B  	xsd:dateTime	xsd:dateTime	op:dateTime-equal(A, B)

and op:dateTime-equal links to

which says
Summary: Returns true if and only if the value of $arg1 is less than the value
of $arg2 according to the algorithm defined in section of [XML Schema
Part 2: Datatypes Second Edition] "Order relation on dateTime" for xs:dateTime
values with timezones. Returns false otherwise.
section of XML Schema is

Err - an example XML Schema has is:

xs:dateTime("2002-04-02T23:00:00+06:00")) returns true.

but that's wrong - it's false by the summary text.  The algorithm returns 
indeterminate and that's not true.  It's also false if default
time zone applies for any time zone that isn't -05:00 at time of execution.

The chain of links from rq25 makes no mention of default timezone because
there is no path to what XQuery adds over XMLSchema.  You showed a
definitive chain from XQuery - but SPARQL needs a chain to that text.

Your proposed text would bringing in something that isn't there now.
The test we have is "Does it change any implementation?"

It changes test open-world/date-2.rq for timezone not Z.  Although that is for 
xsd:date, xsd:date testing is based on xsd:dateTime of the start point.

It would fail for me from end March to end October if the default time zone 
rule applied - it would pass for me the rest of the year.  Unless I was on a 
US trip.

== What's the right (= semantic web) answer?

Aside from all the spec chasing, what's the right answer?

Consider a meeting starting at:


11am; no timezone.  I want to know if someone in the UK can phone in for the
start of the meeting. UK working hours are 09:00-17:00 +01:00

FROM <http://example/meeting.rdf>
   ?person :startWork ?startWork
   ?person :finishWork ?finishWork
   FILTER ( ?startWork > "2007-09-10T11:00:00"^^xsd:dateTime &&
            ?finishWork < "2007-09-10T11:00:00"^^xsd:dateTime )

 From the query and the data, there isn't enough information.

If the default time zone is EDT, the answer to the query is "yes".
If the default time zone is PDT, the answer is "no".

So a semantic web agent should not get true from the
query above.  Same if the question is turned around and
if I ask if the
meeting starts outside of UK working hours.

There is another problem: the text in F&O for dateTime-equal says "true if
$arg1 same as $arg2 else false".  Indeterminate is false.  But then open world
negation is broken because "ne" makes "don't know" to be "true".


  Hewlett-Packard Limited
  Registered Office: Cain Road, Bracknell, Berks RG12 1HN
  Registered No: 690597 England
Received on Monday, 10 September 2007 20:51:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:51 UTC