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 Monday, 1 August 2005 23:04:44 UTC