Re: Functions on Dates, Times and Durations

Gentlepeople,

At 08:23 2003-12-19 Friday, Bernhard Bodenstorfer wrote:

>The origin of most problems with durations is that
>they depend on a reference dateTime so that they can
>be unambiguously interpreted.
>
>1: Don't process durations without a reference
>dateTime
>-------------------------------------------------------
>
>Because if you do, then trouble starts. Let me pose a
>provocative question:
>
>Are there really worthwile use cases that require
>duration processing without a dateTime to relate to?

Well, that depends on whose definition of "worthwhile" you're using.

Most people involved in, say, the food industry would think that the 
duration of "1 hour 30 minutes" would be important without regard to a 
specific dateTime, as in "cook at 200°C for 1 hour 30 minutes".  Similarly, 
a courier service whose business depends on their guarantee that "we'll 
deliver anywhere in the same country within 18 hours" would certainly like 
to be able to prove the truth of that statement automatically (which means 
they need to represent it in their original XML documents).

You might not think these are "worthwhile use cases", but a lot of real 
users out there in the community will certainly think so.  What about 
somebody who wants to find out how long in advance of a party --- any 
party, on any day --- they have to start preparing food, when they have 
only a single oven and 4 dishes that require the use of that oven...to be 
processes serially.  Surely they'll want to add together all of those 
durations, even though they haven't decided whether to hold the party on 
Friday, Saturday, Christmas, or 3 years from now.

>Actually, I have an impression that when one tries to
>e.g. compare durations without a dateTime, one should
>rather look for the flaw in the design.

This is an astonishing statement.  What about "do I have time to cook 
dinner between the time my wife phones me to say she's leaving work and the 
time she gets home --- even though I do not yet know when she'll be phoning 
me?"  All I care about in that comparison is knowing whether the meal 
preparation time is less than, greater than, or the same as my wife's 
travel time.

Any dateTime that I might use in performing such comparisons is entirely 
arbitrary and doesn't really have anything to do with the problem I'm 
solving.  As a poor husband trying to get dinner ready for his family, I 
don't want to have to remember to slip in an unnecessary date (e.g., 
January 1 at noon) just to compare the length of time it takes for me to 
prepare a meal with the length of time it takes for my wife to drive home.

>On the other hand, as long as it is passed on together
>with a dateTime, the use of durations can be
>justified. They are human-readable and I believe that
>all desired operations with durations can be put on a
>solid ground if a reference dateTime appears in some
>place.
>
>For example, if you have a reference_dateTime, then it
>is easy to compare. You just compare dateTimes:
>
>reference_dateTime + duration_1 < reference_dateTime +
>duration_2

Sorry to be so strong in my disagreement, but I do feel very strongly that 
durations exist, and should be manipulable, in the absence of specific 
dateTimes.

Hope this helps,
    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 Friday, 19 December 2003 13:54:37 UTC