Re: Action 695 argument

Changhai Ke wrote:
> Some comments below.

[A minor request but would it be possible to configure your mailer to 
block quote the text you are replying to? That makes it easier to follow 
a thread like this.]

> -----Original Message-----
> From: Dave Reynolds [] 
> Sent: Tuesday, February 03, 2009 3:10 PM
> To: Changhai Ke
> Cc: RIF WG
> Subject: 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.
> [Changhai] This is also my examples, see below. And when a date has no
> timezone, the timezone is just undefined, we don't have to assume that
> the timezone will be the local one. We just don't care, the running
> engine will define the time zone, which will become the timezone for the
> dateTime. 

No. The running engine must not "define the timezone" if is implementing 
xsd:dateTime correctly. If it receives an xsd:dateTime without a 
timezone it has to treat it as such and apply the comparison and 
equality algorithms accordingly. If it converted it to a timezoned 
dateTime (using any timezone, including the local one) it would be 
violating the specs.

>> 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?
> [Changhai] Not sure what you mean. For my part, I meant that we should
> leave xsd:dateTime in RIF and not try to fix it. W3C will fix this (will
> or will not, whatever), and OWL says that owl:dateTime is not
> guaranteed. Double reason to wait for fixes from W3C and not to
> anticipate unnecessarily.

The "fix" would presumably be the introduction of a new 
xsd:dateTimeWithRequiredTimeZone type. If RIF adopts xsd:dateTime it 
does not benefit from any such fix.

> 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 
> owl:dateTime?
> [Changhai] My point is precisely that dateTime without timezone have its
> application. I thought that I expressed my point clearly.
>> 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.
> [Changhai] I don't understand your point. How do you represent
> "12/20/1970" without a timezone? If xsd:date is not in RIF, then I
> should represent it with xsd:dateTime, right? 

No. This is a separate issue from the one about timezones but you can't 
have an xsd:dateTime without a time component (or without a date 
component for that matter which your later example requires).  If you 
want to express these then you should request that RIF also require 
support for xsd:date and xsd:time.  The timezone issue still applies to 
both of those.

> Precisely if I use
> owl:dateTime, I will be thinking hard what will be the timezone, while
> initially there is no timezone concept. (A person born somewhere can
> change timezone and have birthday locally).
>> 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.
> [Changhai] We have a misunderstanding here. A date may not have a
> timezone, and we don't have to care about it, at least from a production
> rule point of view. We make sure that the same date is restored on the
> other side, this is the role of the interchange. After this it will
> happen what will happen.

Dates can have timezones and in some applications you care about this. 
If say a product will be shipped on 5/2/2009 but I ship 8 hours late I 
should not be able to claim I was still on time just because there is 
some timezone in the world where it was still 5/2/2009 when I shipped. 
This is true even in a production rule world :-)

Let me try to be clearer. Let's take your example rule:

   For any restaurant booking in 12/31
   between 5:00pm and 9:00pm, give a 10% discount

Set aside that you need xsd:date and xsd:time to represent this rule, 
(xsd:dateTime is not sufficient).

When the receiving rule engine runs this rule in a production rule 
setting then it presumably runs it over some working memory which 
contains a restaurant booking with a dateTime attached. In normal 
circumstances that will be a real timezoned dateTime (in the local 
timezone) - that's certainly what you'll get if you instantiate a Java 
Calendar object. Your rule, if it is implementing xsd:dateTime 
correctly, will be comparing a non-timezoned date and time constraint 
with a timezoned working memory value in which case it must use the 
"+/-14 hours" algorithm defined in of [1]. On that basis the 
rule can never be satisfied. It doesn't express what you want it to.



Received on Wednesday, 4 February 2009 00:30:13 UTC