W3C home > Mailing lists > Public > public-qt-comments@w3.org > March 2004

[F&O] CER-16 Functions of Durations, Dates, and Times

From: Mary Holstege <holstege@mathling.com>
Date: Thu, 4 Mar 2004 06:49:27 -0800
Message-ID: <16455.16887.21000.202393@gargle.gargle.HOWL>
To: public-qt-comments@w3.org

F&O [9] Functions of Durations, Dates, and Times

The dateTime, date, and time component accessors are not very useful, as they
always return the values for Z (UTC) rather than for the implicit timezone or
some specified timezone. Thus for 12/31/2003 at 9am (Pacific) you get 2004
rather than 2003 as the year. This is because they are defined in terms of the
XML Schema canonical forms, which are always in UTC (if a timezone is present
at all).

Similarly, we find the description of the operation of the functions in
section 9.6 (adjusting to timezone) and hence their utility unclear, as results
are shown with strings, none of which is the result of casting a date or
dateTime to a string, as none is in canonical form. Given the nature of the
component accessors, it is unclear what the benefit of adjusting the timezone
might be.

Many of the date/time/duration-related functions and operators are of very
limited utility and add a great deal of implementation cost and user
confusion. Suggest removing all the functions in section 9.4, as the ISO8601
time formats are readily parsable as strings, perhaps replacing them with
functions to map dayTimeDuration and monthDayDurations to numeric
values. Suggest removing all the functions in section 9.6 as well as the
multiplication and division operators in section 9.5 as being of very marginal
utility for the cost. The net effect would be substantial reduction in the
number of functions that implementors must implement and that users must be
aware of, with no substantial loss of functionality. 

If the dateTime and time component accessors are kept, then please add a
parameter indicating which timezone the accessor should be applied to, or
specify that the accessor should be performed relative to the implicit
timezone, or specify that the component should be the value of the component in
the underlying value space. 

If the timezone adjustment values are kept, it might be appropriate to define
them as returning string values, or to define functions that will render
dateTime, time, or date values as string values relative to some timezone (the
underlying timezone component in the value space, the implicit timezone, or a
timezone given as a parameter to the function).
Received on Thursday, 4 March 2004 10:11:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:56 UTC