W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2003

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

From: David Holmes <dholmes@tibco.com>
Date: Thu, 8 May 2003 12:14:05 -0400
Message-ID: <339902DC0E58D411986A00B0D03D843201C022FE@extmail.rtp.tibco.com>
To: "'Kay, Michael'" <Michael.Kay@softwareag.com>, David Holmes <dholmes@tibco.com>, "'public-qt-comments@w3.org'" <public-qt-comments@w3.org>

	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

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.




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, 15 November 2002)
> fn:get-hours-from-dateTime(xs:dateTime("1999-05-31T13:20:00-05
> :00")) returns 13,
> now (Section, 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

> 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

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

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