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

RE: timezones (was: SAG-FO-02 follow-up: Durations)

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Tue, 23 Sep 2003 11:54:51 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106073DD13E@daemsg02.software-ag.de>
To: Xavier Franc <xfranc@online.fr>, public-qt-comments@w3.org
> 
> Additional remarks about timezones: it seems there are some 
> issues here. Some were already addressed by David Holmes in may 2003.

Yes. There will always be issues with timezones (sigh).
> 
> 
> - The current behavior of date/time component extraction functions
>    like get-hours-from-dateTime is to return components of 
> the normalized value (UTC).
> 
>    It means for example that (excerpt from the current draft, 
> section 9.4.10):
> 
>    [with an implicit timezone value of -05:00]
>       fn:get-hours-from-dateTime( xs:dateTime("1999-12-31T12:00:00") )
>    returns 17 !!!
> 
>    This is very disconcerting and, to put it bluntly, nonsensical.

I think this depends on your viewpoint. There is no right answer here, and
there is no way of making timezones easy. We have adopted the viewpoint,
which is based on the way that XML Schema defines these data types, that the
"value" of the dateTime is the instant in time that it represents, but we
are retaining the original timezone information in addition to the "value"
so that it can be reconstituted if needed. Since two dateTimes are equal if
they represent the same instant, I think there is some logic in saying that
the values returned for the get-hours-from-dateTime() should be the same for
two dateTimes that are equal to each other. But I agree with you that this
won't seem intuitive to everyone.


>    I think authors of books about XML Query/XLST will have a hard time
>    to explain that to their readers!
> 
>    Naive users working in their own implicit timezone should 
> not have to care about
>    the actual timezone and have to do complex adjustments to 
> get correct results.

Users who don't care about timezones (and I'm afraid that we Europeans who
live in single-timezone countries are in a minority here) can use dateTimes
without a timezone component, and they will then achieve this effect.
> 
> 
> - Then what is the meaning of functions adjust-XXX-to-timezone ?
>    what can be adjusted ?
>    The WD gives this example among others:
> 
>     fn:adjust-dateTime-to-timezone( 
> xs:dateTime("2002-03-07T10:00:00-07:00"),
>                                     xdt:dayTimeDuration("PT10H"))
>        returns 2002-03-08T03:00:00+10:00
> 
>     But due to the normalization this is exactly the same thing!
>     So the function is the identity ?

No, it's not an identity. A dateTime has two components: the instant that it
represents, and the preferred timezone to be used in its representation.
adjust-timezone changes the preferred timezone without changing the instant
represented. 
> 
>     Or is there a confusion between the object and its external string
>     representation ? Then we are in fact speaking of 
> formatting functions.

In XML Schema, the timezone is not part of the value space, it is only part
of the lexical representation. We decided in XPath to give the timezone a
higher status than this, so that although it plays no part in value
comparisons, it is retained as an auxiliary part of the value. We felt that
users would not appreciate it if an identity transformation lost the
original timezone information.

Michael Kay
Received on Tuesday, 23 September 2003 05:55:51 UTC

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