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

Mary:
You may have missed the paragraph at the start of 9.4 that explains that
the extraction functions, in fact, work on the localized value of
dateTime etc.  See below.

"The extraction functions specified below extract a single component
from a duration, date or time value. For xs:dateTime, xs:date and
xs:time the localized value is used. To get the value of a component
from the normalized value, the xs:dateTime, xs:date or xs:time must
first be adjusted to UTC or timezone Z. This is illustrated in some of
the examples in this section." 

The "adjustment" functions in 9.6 take a date/time in one timezone and
return the identical instant in another timezone.  I think this is
useful and we have not had any comments recently that they be removed.

As for the other date/time/duration functions, yes, there are a large
number of them.  We have had considerable discussion on them (before you
were a member of the WG) and the content of the F&O reflects the status
quo.  I'm reluctant to reopen this issue, or we will never get done!

All the best, Ashok

-----Original Message-----
From: public-qt-comments-request@w3.org
[mailto:public-qt-comments-request@w3.org] On Behalf Of Mary Holstege
Sent: Thursday, March 04, 2004 6:49 AM
To: public-qt-comments@w3.org
Subject: [F&O] CER-16 Functions of Durations, Dates, and Times



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, 11 March 2004 14:36:41 UTC