Re: Action 695 argument

Changhai Ke wrote:
> Hello all,
> Per my action, please 
> read below my answer.
> During the F2F 12, it was proposed to replace xsd:dateTime 
> ( by owl:dateTime in RIF DTB, 
> because the former does not deal well with timezone (more precisely 
> timezone is optional). I was against this replacement and my argument is 
> the following. (Acknowledgement: I’m not an expert of date 
> representation. Please correct if something is wrong).
> 1. Xsd:dateTime allows representing dates with or without a timezone. 
> The timezone in xsd:dateTime is necessarily UTC. Initially, if you have 
> a date without a timezone, you can easily represent it in xsd:dateTime. 
> If you have a date with a timezone, you can (must) convert it into UTC 
> and store it in xsd:dateTime. So in terms of information preservation, 
> this type does not have any weakness.

The issue is that some applications, such as the examples given by Gary, 
treat a dateTime without a timezone as if it were a dateTime within the 
timezone of the current Locale. This different from xsd:dateTime. If you 
converted such a dateTime-in-local-timezone to either an 
xsd:dateTime-in-UTC or xsd:dateTime-without-timezone then you are 
changing the semantics.

> The type also supports order relations and date arithmetic. It is 
> defined in the specification how dates with and without timezones can be 
> compared.


> 2. In general, it is simpler and straighter to keep XML types without 
> replacement. With the widespread of the web services, there are already 
> numerous utilities to manipulate xsd:dateTime. Moreover, W3C Schema 
> group may fix this issue, and we’ll benefit from it. Owl:dateTime itself 
> is also at risk (see:, search for 
> “**Feature At Risk #3: /owl:dateTime/ name”).**

First, adopting a fixed xsd:dateTime-with-required-timezone would indeed 
be preferable. The issue is one of timescale, do you propose postponing 
adoption of dateTime in RIF until XML Schema has been changed and 
reversing our decision to use XML Schema 1.0?

Second, if you are happy to adopt the fixed 
xsd:dateTime-with-required-timezone and if we agree that that is 
precisely what owl:dateTime is then what is the problem with adopting 

> 3. There are also use cases where the timezone information is missing or 
> is irrelevant. For example, when you want to write a birth date (eg: 
> “12/20/1970”), you write it without a timezone. I don’t know how this 
> can be represented in owl:dateTime, but it is straight to represent it 
> in xsd:dateTime.

Actually that is an xsd:date not an xsd:dateTime, they are different 
primitive types. At the moment RIF is not proposing to adopt xsd:date, 
xsd:time, xsd:gYear etc.

> If I write this production rule: “For any restaurant booking in 12/31 
> between 5:00pm and 9:00pm, give a 10% discount”. My rule does not have 
> any timezone, it is intrinsic and can be applied to all the locations. 
> Of course, the executing environment needs to be well set (for example 
> there will be a rule engine for the east coast timezone, while another 
> one will be for the central Europe), but the rule content itself does 
> not need to refer to any timezone.

That is precisely the case I outlined above. You cannot use xsd:dateTime 
for that because you are assuming that a non-timelined xsd:dateTime 
corresponds to the current Locale timezone which it doesn't. If your 
application assumes this convention, but sends the RIF rules to a 
different application which does not make this assumption you will get 
incompatible results.

In particular a correct implementation will only fire that rule if the 
current time (which would be in UTC) is 14 hours after 5:00pm and 14 
hours before 9:00pm, i.e. never.

> I hope this is clearer. Maybe someone can explain why it is important to 
> replace xsd:dateTime by owl:dateTime, or we consider this topic as closed.

I hope the above has clarified the problems.

As I see it we have several options:

(1) Remove the ambiguity by enforcing all dateTimes to have timezones. 
This means either adopting owl:dateTime or waiting until there is an XML 
Schema change.

(2) Adopt xsd:dateTime but reduce the ambiguity, for example by adding 
an explicit specification that xsd:dateTime values without a timezone 
should be treated as in the timezone of the Locale of the running rule 

(3) Adopt xsd:dateTime, leave it ambiguous, and put an explicit warning 
in the text that the sort of assumption made in your restaurant rule is 
not safe and that different RIF implementations may act in different ways.

My preference is (1) on grounds of simplicity, lack of ambiguity and OWL 
compatibility. However, I don't think I'd formally object to any 
solution, I just want us to be clear what we are choosing.

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

Received on Tuesday, 3 February 2009 14:11:12 UTC