W3C home > Mailing lists > Public > public-i18n-core@w3.org > July to September 2005

RE: Time zone handling in QT

From: Addison Phillips <addison.phillips@quest.com>
Date: Mon, 1 Aug 2005 10:10:12 -0700
Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C4AB04E@irvmbxw01.quest.com>
To: "Mark Davis" <mark.davis@icu-project.org>, "Martin Duerst" <duerst@it.aoyama.ac.jp>, <public-i18n-core@w3.org>, "Felix Sasaki" <fsasaki@w3.org>
Cc: <ashok.malhotra@oracle.com>
Hi All,

It *is* a Wiki, so enter edits directly (please mark them up by wrapping them in square brackets [[ like this so I can see them ]]). Note that clicking on  he "Subscribe" link at the top of the page will generate modification notes from the Wiki (provided you create an account on the Wiki and sign in when viewing the page--don't worry, it keeps cookies).

In this particular case I have started to incorporate Mark's text into the Wiki page and work on Felix's additions. One problem I note is that Martin's recipe text does not contain all of the recommendations (others are scattered throughout).

In the most recent edit:

1. I moved Martin's health warning near the top of the page rather than buried in the recommendations.

2. I incorporated Mark's text (below) and began to edit it into the flow.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: Mark Davis [mailto:mark.davis@icu-project.org]
> Sent: Saturday, July 30, 2005 10:34 AM
> To: Martin Duerst; Addison Phillips; public-i18n-core@w3.org; Felix Sasaki
> Subject: 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 Monday, 1 August 2005 17:10:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 October 2008 10:18:49 GMT