- From: Mary Holstege <holstege@mathling.com>
- Date: Thu, 4 Mar 2004 06:49:27 -0800
- 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