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:49:12 UTC