RE: Time zone handling in QT

Hi Ashok,

We're getting there, I think. I tend to agree that the "recipe" portion isn't worked out thoroughly. Some of the background material may not end up being directly useful in F&O. I think by the end of the week we could have something that is in pretty good shape. This might recommend a particular course of action (Note, distillation, or direct insertion)... or some combination thereof.

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: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
> Sent: 2005?8?2? 12:49
> To: Mark Davis; Addison Phillips; Martin Duerst; public-i18n-core@w3.org;
> Felix Sasaki
> Subject: RE: Time zone handling in QT
> 
> I looked at the Wiki page.  I think the information is too much and too
> discursive to go directly into the F&O.  I think we have two alternatives.
> 
> - Publish as W3C note and add a pointer from the F&O to the note.
> - Distill the information down to what the users needs to know and add
> as an appendix to the F&O.
> 
> I'll be glad to do the editing required for option 2.
> 
> All the best, Ashok
> 
> 
> > -----Original Message-----
> > From: Mark Davis [mailto:mark.davis@icu-project.org]
> > Sent: Monday, August 01, 2005 4:03 PM
> > To: Addison Phillips; Martin Duerst; public-i18n-core@w3.org;
> > Felix Sasaki
> > Cc: ashok.malhotra@oracle.com
> > Subject: Re: Time zone handling in QT
> >
> > Ok, started editing.
> >
> > Fixed java reference; they also use 1970, and milliseconds
> > not seconds.
> > Added pointer to "universal time"
> > Fixed reference to midnight. (never use without
> > qualification, since midnight 2005-9-10 can mean before
> > 00:00:01 or after 23:59:59 -- 24 hours
> > apart!)
> > Many text changes; changed used of 'wall time', since it was
> > used for two very different things. And computer time vs wall
> > time are really misnomers:
> > used timezone-independent and timezone-dependent. But this
> > still needs more thought.
> > Ordered some text.
> > Still needs much more work.
> >
> > şMark
> >
> > ----- Original Message -----
> > From: "Addison Phillips" <addison.phillips@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>
> > Sent: Monday, August 01, 2005 10:10
> > Subject: RE: Time zone handling in QT
> >
> >
> > > 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 Tuesday, 2 August 2005 19:52:50 UTC