W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2003

Re: Functions on Dates, Times and Durations

From: Bernhard Bodenstorfer <bodenstorfer@yahoo.co.uk>
Date: Fri, 19 Dec 2003 15:23:17 +0000 (GMT)
Message-ID: <20031219152317.44925.qmail@web25102.mail.ukl.yahoo.com>
To: public-qt-comments@w3.org
Cc: bbodi@web.de

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

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?

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.

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

For example, if you have a reference_dateTime, then it
is easy to compare. You just compare dateTimes:

reference_dateTime + duration_1 < reference_dateTime +

(I think it is not difficult to understand the idea,
though I used a sloppy "<" and a non-existing operator
Secret advice for those who would not refrain from a
healthy hack at times: You can always come up with an
artificial fake reference_dateTime (like
2001-01-01T00:00:00Z) if you really want to handle
durations alone.

Let me conclude this topic expressing my concern about
a quite large API when many functions are only
necessary to bypass various headaches with durations
that have no dateTime as a basis. I would rather
honestly admit that simply you should not even think
of doing it without. And I would only offer functions
with a dateTime.

The "+" operator brings me to my second topic:

2: There should be a function to add dateTime +

To illustrate why I believe that such an operator or
something similar to the EXSLT function date:add(
dateTime, duration ) should be available, let me
shortly present the following use case:

In a financial time series database, there are series
with different measurement frequencies: daily, weekly,
monthly, quarterly, semi-Annual, annual. Corresponding
to those are enumerated duration codes P1D, P7D, P1M,
P3M, P6M, P1Y. For each time series, the starting
dateTime and the duration code is needed in order to
enumerate the dates corresponding to the values

Assuming a function date:add( date, duration ) exists,
I just take the start dateTime and the duration code
to iteratively (in the template recursion) compute the
dateTimes I need. Of course things may get even
simpler if we have a "saxpy"-type operation with three
arguments to express "dateTime + n * duration". This
would (using a divide in half recursion or even a
foreach-loop rather than an element-wise recursion)
alleviate problems with very long time series.

Let me conclude this topic: I acknowledge that the
addition dateTime + duration is possible also if the
duration is cleanly split into two parts as it is
currently foreseen. However, for simple applications
like the one sketched, I feel that the machinery one
has to involve is a bit complicated.

With kind regards,

Bernhard Bodenstorfer



PS: Search for the typo in the WD: "semnatics"

--- END ---

Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
Received on Friday, 19 December 2003 10:30:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:15 UTC