Re: Time zone handling in QT

One of the things I notice about this is that it does not describe what to
do with wall time. I suggest adding some of the following material to the
FAQ (as a Wiki, should I just edit stuff in, or do you have a single
editor?).

Wall Time. When a calendar system schedules a recurring meeting for 08:00
Pacific Time, it is referring to what is known as "wall time". This is *not*
equivalent to either 08:00 GMT-8 or 08:00 GMT-7, because it does not have a
fixed offset from GMT (UTC); instead, the offset changes over time. The
calendar system must use an ID for the timezone (which is by reference, a
set of rules for computing what that GMT offset is over time). The most
definitive reference for dealing with wall time is the TZ database (aka
Olson timezone database, http://www.twinsun.com/tz/tz-link.htm), used for
UNIX, Java, CLDR, ICU, and many systems and libraries. In the TZ database,
"Pacific Time" is denoted with the internal ID America/Los Angeles (or
America/Los_Angeles to avoid spaces).

The TZ database supplies aliases among different IDs. The database supplies
also aliases between different IDs; for example, "Asia/Ulan Bator" is
equivalent to "Asia/Ulaanbaatar". From the equivalence class formed by these
alias relations, a canonical form can be derived. CLDR can be used to
provide a localized form for the IDs: see Appendix J in
http://www.unicode.org/reports/tr35/.

Whenever a time is stored without a fixed date, the user should provide a
fixed GMT offset (*if and only if* it is truely fixed) or accompany it with
the appropriate TZID. When comparing time + TZID, a <time, TZID> can be
compared as equal to another iff the time is identical and the TZIDs have
the same canonical form. It is also possible to have a looser comparison,
whereby <time, TZID> is compared to <time1, TZID1> over some interval of
time: if they have the same offsets during that period, they are considered
identical.

There are different ways to do ordered comparison of <time, TZID> pairs. The
simplest is simply to put both in canonical form, then order them first by
time then by TZID.

[There are a few current limitations in the TZIDs; I can follow up with
those.]

‎Mark

----- Original Message ----- 
From: "Felix Sasaki" <fsasaki@w3.org>
To: "Martin Duerst" <duerst@it.aoyama.ac.jp>; "Addison Phillips"
<addison.phillips@quest.com>; <public-i18n-core@w3.org>
Sent: Saturday, July 30, 2005 09:16
Subject: Re: Time zone handling in QT



Hello Martin,

On Sat, 30 Jul 2005 13:49:26 +0900, Martin Duerst <duerst@it.aoyama.ac.jp>
wrote:

> Hello Felix,
>
> Some comments below.
>
> At 16:44 05/07/27, Felix Sasaki wrote:
>  >
>  >Hi Addison, hi all,
>  >
>  >I made some concrete proposals for XQuery / XSLT users and integrated
> them
>  >into the Wiki [1]. Please comment them / change them as you like. I
> added
>  >the following:
>  >
>  >Recommendations for XQuery / XSLT
>  >
>  >The following recommendations are for users of XQuery / XSLT who have
> to
>  >deal with time zone sensitive data:
>
> I think this is the wrong start. Many people will think that it
> doesn't concern them. But most people are affected, sooner or
> later. The intro should make that clear.

That's a good point. I will change that to:

"The following recommendations are for users of XQuery / XSLT. They should
take them into account even if they do not deal with time zone sensitive
data regulary, since sooner or later they will be affected by the issues
described."

Regards, Felix.

>
> Regards,   Martin.
>
>
>  >    1.
>  >       If possible, make sure that your data always contains an
> explicit
>  >time zone which should be UTC (i.e. computer time).
>  >    2.
>  >       Do not apply any operations based on date / time types (e.g.
>  >indexing) if you are not sure (a) whether your data has time zone
>  >information at all, or (b) whether the data collection might encompass
> a
>  >data subset without timezones or might mix computer and wall time.
>  >    3.
>  >       If you have data like 2, before applying any date / time
> sensitive
>  >operations, adjust the time zone of the data to UTC with the functions
> for
>  >time zone adjustment, cf. [WWW]
>  >http://www.w3.org/TR/xpath-functions/#timezone.functions.
>  >    4.
>  >       If you have data like 2 (b) and you do not want to adjust the
> data
>  >subset which already has a time zone, make sure that you recognize this
>  >data subset, e.g. via the component extraction functions [WWW]
>  >http://www.w3.org/TR/xpath-functions/#d1e4771.
>  >
>  >
>  >-- Felix
>  >
>  >[1] http://esw.w3.org/topic/i18nFAQTimeZone
>  >

Received on Saturday, 30 July 2005 17:34:32 UTC