RE: [Bug 1334] no implicit conversion between time zones

All:

Regarding Paul Cotton's note (at the bottom), I would like to send the following response on our behalf.

Please note that I have a paper on this topic that makes good bedtime reading (in case you want to brush up on the topic): http://www.inter-locale.com/demos/about-time/about-time-ext.xml (format is XHTML)


Comments, please?

Addison

===
Dear Paul,

Apologies for not detailing our WG position sooner.

I will poll the WG for a good time. Only a few of us are in the Pacific time zone and we generally have our calls quite early (8 a.m. PDT is typical) in order to reach most of our participants. Later calls are possible if we just send a couple of representatives (which is probably the most appropriate course of action).

Here is a summary of our WG position as I understand it (since Martin and I originated these comments, I think it is pretty close to accurate).

Here is the definition in Section 2.1.2 that we are concerned about:

---
[Definition: Implicit timezone. This is the timezone to be used when a date, time, or dateTime value that does not have a timezone is used in a comparison or arithmetic operation. The implicit timezone is an implementation-defined value of type xdt:dayTimeDuration. See [XML Schema] for the range of legal values of a timezone.]
---

The implicit time zone presumably (although not normatively) represents the local offset from UTC. This value has a troublesome relationship with the values being processed. For example, the xdt:dayTimeDuration for the America/Los_Angeles time zone varies depending on whether the time zone is in Daylight Savings Time (Summer Time) or not. If the offset is taken in June and the 'date' value is "2004-02-01", the wrong offset may be applied and the results could be skewed.

Complicating this matter is the fact that the XML Schema types try to fit different quality date/time values into the same data type. Some date and time values mirror the common SQL types with similar names and represent "wall time" (that is, "2005-07-06" represents that date in all time zones--it might be some person's date of birth, for example). 

Other date, time, and dateTime values mirror the local programming environment equivalent of time_t or java.util.Date (let's call it "computer time"): an offset in milliseconds from the local epoch expressed as a string and generally bearing a time zone indicator if local time was used and either "Z" or no indicator if UTC was used.

Comparisons of like-to-like present no problems, although the implementations should be different (i.e. producing logical results). For example, the implicit time zone should not be used to create computer times when comparing two items of type 'date' with no time zone (and representing wall time). This prevents events like daylight savings time transitions from affecting the results.

Comparisons of disparate types require one type or the other to be coerced. Since computer times are sometimes represented as time-zone-less values, this may be complicated: it may not be apparent what the types represent "really". The implicit time zone represents a kind of "final fallback" for performing the coercion, but it is variable and will produce different results depending on time of year, location, configuration, and implementation--not to mention the specific values of the inputs.

Conclusion:

It would be better to both a) state that the implicit time zone is UTC* and b) allow every comparison operator to specify a time zone that would be used for values without a time zone [allowing control for those who need it]

* [making the implicit time zone UTC has advantages for wall time to wall time comparisons: these can then be coerced safely. Since UTC does not use DST, the offsets are always the same, and the results of a round trip between the implementation internal representation and the string should be the same as well. In addition]

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: Paul Cotton [mailto:pcotton@microsoft.com]
> Sent: 2005?7?6? 15:08
> To: fsasaki@w3.org; Addison Phillips
> Cc: member-query-coord@w3.org
> Subject: RE: [Bug 1334] no implicit conversion between time zones
> 
> If we are to have a joint call I think the best plan would be to do it
> during the XQuery/XSL joint F2F meetings during the period Tue-Thu Jul
> 19-21.
> 
> We are meeting in the PST timezone.  What day and time of day would be
> convenient for the I18N WG?
> 
> BTW your original comment stated:
> 
> Sec. 2.1.2, Definition of an "Implicit time zone"
> This has to be removed. Using implicit conversions between timezoned and
> non-timezoned dates and times is way too prone to all kinds of subtle
> and not so subtle bugs.
> 
> Our feedback is recorded in the bug entry dated Jun 10.  It would help
> the discussion if instead of just rejecting our position you explained
> in more detail the changes you want us to make.  In particular it would
> help if you let us know if any of the alternatives we rejected are in
> your preferred solution space.
> 
> /paulc
> 
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Nepean, Ontario K2E 6A3
> Tel: (613) 225-5445 Fax: (425) 936-7329
> mailto:pcotton@microsoft.com
> 
> 
> 
> > -----Original Message-----
> > From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> > request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
> > Sent: July 6, 2005 3:31 AM
> > To: public-qt-comments@w3.org
> > Subject: [Bug 1334] no implicit conversion between time zones
> >
> >
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=1334
> >
> >
> > fsasaki@w3.org changed:
> >
> >            What    |Removed                     |Added
> >
> ------------------------------------------------------------------------
> --
> > --
> >              Status|RESOLVED                    |REOPENED
> >          Resolution|WONTFIX                     |
> >
> >
> >
> >
> > ------- Additional Comments From fsasaki@w3.org  2005-07-06 07:30
> -------
> > consensus of the i18n-core wg (telecon 6 July 2005):
> >
> > A problem remains: What do you do if have several documents, with
> several
> > (implicit) timezones? We don't think that your solution is
> interoperable.
> > We
> > propose to have a joint call between the working groups on the topic.
> > Please
> > tell us a convinient time.
> >
> > Best regards, Felix Sasaki.

Received on Wednesday, 6 July 2005 23:33:02 UTC