Re: Action 695 argument

Changhai Ke wrote:

> [Changhai] It is essential that the rule engine can interpret the
> dateTimes it encounters in the rules, with or without timezones. As a
> reminder, we saw that comparison between dateTimes without timezone is
> possible and defined in the spec. 

Agreed, I've acknowledged multiple times the comparison is well defined.

> As an interchange, the most important is to acknowledge the existence
> and usefulness of dateTime without timezone. When the business person
> expresses the restaurant rule (between 5:00 and 9:00 pm give 10%
> discount), that rule is valid everywhere, for all the timezones. As a
> rule, it is intrinsic. We cannot force business people to add a timezone
> (if so, he will have to express the same rule for 24 timezones,
> ridiculous!) This rule then gets to be deployed, to simplify let's say
> the deployment scheme is that a specific rule engine takes care of a
> time zone. The engine then knows what is its timezone and how to
> interpret dateTimes without timezones that it encounters in the rules.

I certainly acknowledge the existence of dateTimes without timezones. 
The question is their usefulness for interchange in the absence of 
additional guidance.

> The engine can be initialized to work on its local timezone (for example
> a server in NY to take care of EST), or the engine can be initialized
> with another timezone (for example I start an engine in Paris to process
> the timezone EST). 

The engine being initialized with a timezone is irrelevant. If you use 
xsd:dateTime without a timezone then you have to use the comparison 
algorithms - they are not dateTimes in the timezone of the engine.

Also remember that on the web rule sets and data can be coming from 
multiple different locations and that in particular the timezone of the 
data originator may differ from that of the engine.

>> 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 3.2.7.4 of [1]. On that basis the
>> rule can never be satisfied. It doesn't express what you want it to.
>>
> 
> [Changhai] See my previous comment. Here we are manipulating 2 data:
> The first is a dateTime from a rule, without timezone. 
> The engine which attempts to use this dateTime (for example by creating
> a Java object), has already been launched on a specific locale and
> timezome, thus will create a perfectly defined dateTime by adding a
> timezone. Another alternative implementation of the engine will be to
> keep all the dateTimes without timezone, and perform computation and
> comparison relatively between them.

My point is that the only correct implementation is the latter and 
implementers might not realize that without guidance.


So where are we?

o You've convinced me you really do want to write rules with dates and 
times without timezones. I haven't yet seen an example yet where you 
need a *dateTime* without a timezone but I'm beginning to believe there 
might be such a case.

o The discussion has reinforced my impression that implementers will 
mistake dateTimes-without-timezones for dateTimes in the engine's locale 
and that we should give some guidance to help both implementers and RIF 
users.

So it sounds like you might need to propose that RIF adds xsd:date and 
xsd:time (with and without timezone).

Then I think it would be useful for you, Gary and anyone with skin in 
this game (which I don't) to figure out if date and time are enough or 
you also really *need* dateTime without timezones. If you do then we 
have to decide whether we adopt both xsd:dateTime and xsd:dateTimeStamp 
to give maximal overlap with OWL or not.

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

Received on Friday, 6 February 2009 10:36:05 UTC