Re: Functions on Dates, Times and Durations

Bernhard,

At 10:31 2003-12-22 Monday, Bernhard Bodenstorfer wrote:

>Let's re-visit the topics that I raised in
>http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0261.html,
>then garbage-collect Topic 1 and add a new Topic 3.
>
>Topic 1: Don't process durations without a reference
>dateTime
>-------------------------------------------------------------
>
>Jim wrote in
>http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0268.html
>
>... (lines deleted from Jim's response by Jim, responding again) ...
>
>You are right, indeed. Therefore, I take back
>my provocative claim. I agree that durations
>can make sense also without a dateTime,
>particularly the drafted subclass xdt:dayTimeDuration
>does.
>
>... (more lines deleted by Jim in Jim's present response) ...
>
>Your disagreement was completely in order.
>While it may well be that general xs:duration values
>are undesirable without a dateTime, certainly the
>logical concept of a duration cannot be questioned
>and I take that back.

I want to express my thanks for the graciousness with which you discussed 
this.  We sometimes have a tendency to get tense with one another, and you 
have completely avoided that.  Thanks!

>Topic 2: There should be a function to add dateTime +
>duration
>--------------------------------------------------------------
>
>... (Jim deletes some more lines here) ...
>
>The correct observation that some operations
>with xs:duration are problematic
>cannot justify a complete ban on xs:duration
>arithmetic also in cases, where the arithmetic
>does make sense and is easy to grasp.
>Most prominently, adding an xs:duration
>to an xs:dateTime is meaningful.
>(Though you have to specify whether you first add
>the yearMonth part or the dayTime part.)

I recognize the validity of your argument here.  However, the F&O Task 
Force and the Query WG and XSL WG discussed the issue ad nauseum and 
concluded that the avenue with the fewest objectionable consequences was 
simply to prohibit arithmetic involving xs:duration and replace those 
possible operations with operations on the two xdt: subtypes.

I *PERSONALLY* would not find the *addition* of two new functions 
(something like xxx:add-duration-to-dateTime(xs:dateTime,xs:duration) and 
xxx:subtract-duration-from-dateTime(xs:dateTime,xs:duration), where I do 
not take a position right now on whether "xxx" is "fn" or "op") to the F&O 
spec.  I probably would oppose the deletion of the existing 
funcitons/operations involving the two xdt: subtypes of duration.  (Not at 
all incidentally, I know that many people, for very good reasons, oppose 
the addition of still more functions.  In fact, my employer would almost 
certainly object to the addition of these functions in spite of my personal 
lack of objection.)

>... (even more lines deleted by Jim for this response) ...
>
>A method fn:subtract-dateTimes-yielding-duration
>would also be possible, and it is there in EXSLT.
>The resulting duration would naturally relate
>to the first argument of the function.

See my personal feelings, and my prediction of others' feelings, above ;^)

>Topic 3: Use of normalized value in
>add-yearMonthDuration-to-dateTime
>---------------------------------------------------------------------
>
>I have a doubt about
>http://www.w3.org/TR/2003/WD-xpath-functions-20031112/#func-add-yearMonthDuration-to-dateTime.
>
>It says here that the first argument internally is
>normalised first and then the addition happens.
>I feel that this treatment of timezones may
>yield strange results close to a change of month.
>
>Example: Consider the sum expression
>
>2001-03-01T06:00:00 + P1M.
>
>Who would not agree that the expected result
>is 2001-04-01T06:00:00?
>
>First assume I am living in London at timezone 0:00.
>So normalisation has no role and there are
>no other problems, so the result would be
>
>2001-04-01T06:00:00,
>
>which indeed matches my expectations.
>
>Next assume that I am living in Beijing
>with UTC plus 8 hours, and consider
>the same sum expression
>
>2001-03-01T06:00:00 + P1M.
>
>The normalisation away from the default timezone to Z
>then implies interpretation of my sum expression as
>
>2001-02-28T22:00:00Z + P1M,
>
>because it was still late evening in London,
>when it was already early morning in Beijing.
>After the addition of P1M I get
>
>2001-03-28T22:00:00Z
>
>and thus, back in Beijing local time zone,
>
>2001-03-29T06:00:00
>
>So in Beijing, I get
>2001-03-01T06:00:00 + P1M = 2001-03-29T06:00:00.
>
>Note that the problem is not the use of a default
>timezone. I have the same trouble when specifying
>zone +8:00:
>
>2001-03-01T06:00:00+8:00 + P1M =
>2001-03-29T06:00:00+8:00.
>
>I have the feeling that this is wrong.
>But it may be intended in the end. Any views?

My view (personal, not Working Group or corporate) is that the consequences 
you describe are unavoidable in the general case.  We have uncovered 
anomalies all over the place when dealing with dates and times, especially 
near boundary regions...the most notorious of which are month boundaries 
such as the one you described (which is not, of course, limited to 
Februaries).  I believe that the current solution set is a reasonable 
compromise regarding the selection of which anomalies we resolve versus 
those that we do not resolve.  I don't think it's possible to eliminate all 
of the anomalies in the general case, simply due to the nature of 
dates/times as semi-natural values heavily influenced by human politics.

The specific problem you discuss above might be something that could be 
resolved, but I worry that the solution would involve rules such as "If 
there are no anomalies introduced, then normalize the UTC; if there are 
anomalies caused by such normalization that can be avoided by using the 
current timezone, then use the current timezone."  However, such rules are 
difficult to express formally, because the notion of "anomalies" depends 
largely on human interpretations.  Another factor that might help in such 
rules could be "use the length of the following month when resolving such 
anomalies", but I haven't thought out the implications of that at all.

What we really need is a DWIM processor (Do What I Mean), which is probably 
not yet in Alpha testing...

Again, thanks for your continued interest in this subject and its possible 
resolution (or improvement).

Best,
    Jim


========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
Oracle Corporation            Oracle Email: mailto:jim.melton@oracle.com
1930 Viscounti Drive          Standards email: mailto:jim.melton@acm.org
Sandy, UT 84093-1063              Personal email: mailto:jim@melton.name
USA                                                Fax : +1.801.942.3345
========================================================================
=  Facts are facts.  However, any opinions expressed are the opinions  =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =
========================================================================

Received on Monday, 22 December 2003 14:33:07 UTC