Re: Functions on Dates, Times and Durations

Topic 2: There should be a function to add dateTime +
duration
--------------------------------------------------------------

>>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.
[...]
>
>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.

Easily I can imagine that topic being discussed
ad nauseam et ultra. As Ashok points out in
http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0263.html,
the functions with the xdt: types can do the job,
so I would not be overly sad about this solution
either, it is just a bit less convenient to learn
and use.

Though the API looks more complicated,
there is at least one advantage that I acknowledge:
Programmers have to make an explicit decision
(and we can hope that it is a conscious one)
about whether the yearMonth part or the dayTime part
is added first. So from the didactical point of view,
the xdt: solution is preferable.

>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.)

Well, I was not only talking about adding a
function. I would tend to object to that, too,
because the added function would be redundant.
I was talking about replacing the functions
"add xs:dateTime + xdt:dayTimeDuration" and
"add xs:dateTime + xdt:yearMonthDuration" by
one single function
"add xs:dateTime + xs:duration".
Since xs:duration is a supertype of
xdt:dayTimeDuration and xdt:yearMonthDuration,
I would not really delete the two
functions you care about, but interpolate
to form a more powerful function which, still,
gives the same values as the replaced functions
when called with a second argument from the
respective type.
So in net, the API becomes smaller by one
function and xs:durations are easier to treat.
The same applies for the subtraction
xs:dateTime - xs:duration, too.

All this consideration under the premise
that the presently foreseen functions
with the xdt: types are the ones we want...

Actually, I have some doubt whether adding
xs:dateTime + xdt:yearMonthDuration
is a good idea to do in the first place.
It leads at least to surprises with pinned days
which make addition a non-monotonous operation
(i.e. increasing one argument may
surprisingly decrease the "sum":
2003-01-30T18:00:00Z + P1M
is later than 2003-01-31T06:00:00Z + P1M).

I would find it more natural and clean to add
only xs:gYearMonth + xdt:yearMonthDuration.
Somehow I have a bad feeling in the stomach
to provide an operation which is not clean.
Adding one is too easy, the true hassle comes
with removing it later upon better insight.
Would we lose important use cases if we add
xdt:yearMonthDuration only to xs:gYearMonth but
no other types? If not, then let's better do so.

The same applies to adding an
xdt:yearMonthDuration to an xs:date.

(Instead of using the xdt: types, we could, of
course, use numbers for adding to xs:gYearMonth,
too, but this is a secondary topic here, since it's
isomorphic and thus semantically equivalent;
still the API becomes shorter:
xs:gYearMonth + n ... adding n months
xs:dateTime + n ... adding n seconds
xs:gYearMonth - n ... subtracting n months
xs:dateTime - n ... subtracting n seconds
xs:gYearMonth - xs:gYearMonth ... difference in months
xs:dateTime - xs:dateTime ... difference in seconds
where n is
* integer for operations involving xs:gYearMonth,
* double for operations involving xs:dateTime)

By the way, do we have a resource somewhere which
postulates the arithmetic rules that should
hold for the date/time and duration operations?

Topic 3: Use of normalized value in
add-yearMonthDuration-to-dateTime
---------------------------------------------------------------------

>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.

Yes, xs:duration is just one of those beasts
from fuzzy reality out there that is a pain to
automated processing. If IT people had designed
time, it would probably be a straight xs:double. ;)

>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,

What is wrong with a simple rule to always use
the timezone stated with the dateTime
(or the local default timezone in absence of this)?
I mean: Leave away that initial normalisation
to Z zone. I see no nasty side-effects of such
a convention. I'm interested to learn whether
there are such.

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

Unfortunately, what you mean may not be what I mean;
moreover, I have read, and it matches my experience,
that things turn *really* awkward, when software
*tries* to guess what the user "really" wanted,
but of course gets it wrong from time to time...

Cheers,

Bernhard

References:

In reply to:
http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0280.html

Call for arithmetic rules:
http://lists.xml.org/archives/xml-dev/200209/msg01206.html

Using numbers instead of xdt: types:
http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0029.html

--- END ---

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

Received on Tuesday, 23 December 2003 09:01:58 UTC