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

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

From: Ashok Malhotra <ashokma@microsoft.com>
Date: Thu, 11 Mar 2004 11:36:06 -0800
Message-ID: <EDB607C8AC991F40BE646533A1A673E8017EAFBC@RED-MSG-42.redmond.corp.microsoft.com>
To: <holstege@mathling.com>, <public-qt-comments@w3.org>

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
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
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
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
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
component accessors, it is unclear what the benefit of adjusting the
might be.

Many of the date/time/duration-related functions and operators are of
limited utility and add a great deal of implementation cost and user
confusion. Suggest removing all the functions in section 9.4, as the
time formats are readily parsable as strings, perhaps replacing them
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
utility for the cost. The net effect would be substantial reduction in
number of functions that implementors must implement and that users must
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,
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
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

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