RE: dateTime etc accessors now UTC-based, were local

Ashok,
	Thanks for clarification and the explanation of the "tuple" concept;
BTW, I think the "tuple" is a good clarifying feature of the May 2 draft and
could even be employed to further effect by using it to present intermediate
results in the examples in areas where functions are compounded, and in
casting.

	So, the component accessors are UTC!  Would the committee consider
augmenting the UTC accessors with "local" accessors or is there a reason why
this would be a bad idea?  To be definite, I would like to see the old-name
functions being used for "local" accessors and a new set, e.g.
get-utc-hours-from-dateTime(...), being used for UTC accessors. I realize
that this creates some redundancy in the API, but as I try to rationalize
the UTC semantics for accessors I can only imaging that they have fallen out
from a desire to create a spec that is implementation neutral (doesn't deal
with seconds since an epoch). This neutrality is indeed good, but while the
UTC accessors create a kind of canonical consistency, they could be just an
abstract concept used to communicate the spec with "local" accessors doing
the heavy-lifting for users.

Best Wishes,

David

-----Original Message-----
From: Ashok Malhotra [mailto:ashokma@microsoft.com]
Sent: Wednesday, May 07, 2003 5:33 PM
To: David Holmes; public-qt-comments@w3.org
Subject: RE: dateTime etc accessors now UTC-based, were local


That's a good question, David, as it relates to an area in which there
has been significant change in the May 2 draft.

XML Schema defines the value space for all the date/time types as the
value in the UTC timezone.  In the XQuery/Xpath specifications we have
chosen to also keep the original timezone as part of the value.  Thus,
if the lexical form for a dateTime is "2003-05-07T17:30:00-05:00"  this
would translate into a two-part value:  a dateTime in the UTC timezone
2003-05-07T22:30:00 and the timezone -05:00.  

The component extraction functions work on values defined in this
manner.
There were also some bugs in the earlier drafts which have been
corrected.

All the best, Ashok

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of David Holmes
> Sent: Wednesday, May 07, 2003 1:44 PM
> To: 'public-qt-comments@w3.org'
> 
> 
> I noticed that the Last Call (02 May 2003) Functions and Operators
working
> draft has changed from the 15 November 2002 draft in regards to the
basis
> for component accessors functions for dateTime and friends.
> 
> For example, where previously (Section 8.4.10.1, 15 November 2002)
> 
> fn:get-hours-from-dateTime(xs:dateTime("1999-05-31T13:20:00-05:00"))
> returns
> 13,
> 
> now (Section 9.4.10.1, 02 May 2003)
> 
> fn:get-hours-from-dateTime(xs:dateTime("1999-12-31T21:20:00-05:00"))
> returns
> 2.
> 
> It would appear that the basis for component accessors has gone from
local
> (same as lexical) to UTC.  I can understand that the distinction is
> necessary to get everything to work out right, but the user is now
left
> with
> the onerous task of calculating local components and surprising
results
> unless this behavior is made very explicit in the specs.
> 
> Would you be able to point me to some threads on the subject? Did the
> committee consider some parallel functions e.g. get-local-hours-from-
and
> get-utc-hours-from-?
> 
> Thanks,
> 
> David Holmes
> 
> 
>

Received on Wednesday, 7 May 2003 18:40:48 UTC