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

Mike,
	Thanks for the suggestion. Unfortunately, I can't get your
prescription to work out.

Here's my attempt at working through your prescription with some data.

Assume that the evaluation context provides an implicit timezone value of
-05:00.

Let $dt = xs:dateTime("1999-05-31T13:00:00-07:00")

Then in the tuple representation, $dt = ("1999-05-31T20:00:00Z", -PT7H)

Let $a = adjust-dateTime-to-timezone($d, ())

Then in the tuple representation, $a = ("1999-05-31T13:00:00Z", ())

(BTW. I use a rule that addition/removal of timezones is done at "constant
local time", while timezone changes are at "constant UTC" i.e. preserve
simultaneity. Not sure if that is a useful/accurate summary or not!). 

Let $h = get-hours-from-dateTime($a)

Then $h = 18, because of the implicit timezone.

Desired result is $h = 13.

Thanks,

David

P.S.

I think the spec would dramatically benefit from employing the "tuple"
representation that is introduced in Section 1.4. as a way to define
intermediate steps. This might help identify steps where "magic" aka
confusion creeps in.

 

-----Original Message-----
From: Kay, Michael [mailto:Michael.Kay@softwareag.com]
Sent: Thursday, May 08, 2003 10:26 AM
To: David Holmes; 'public-qt-comments@w3.org'
Subject: RE: dateTime etc accessors now UTC-based, were local


> 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.

Actually, the November draft was confused on the subject. The value space
for dates and times, as defined in XML Schema, does not retain the timezone,
so the result shown in the example was not achievable without some special
magic.

> 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.

Timezones, I'm afraid, are always going to generate surprises, whatever we
do.

To get the hours component in the original timezone, I believe that what you
have to do is:

get-hours-from-dateTime(adjust-dateTime-to-timezone($dt, ()))

This might not be very intuitive, but it's not very onerous once you know
what you're doing.
> 
> 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-?
> 

More possibilities were considered than some of us care to remember...

Michael Kay

Received on Thursday, 8 May 2003 12:21:54 UTC