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

Hi Addison,


Sorry for the overlap with the mail about this. I wrote my mail before I  
saw yours.

Best, Felix
On Thu, 07 Jul 2005 08:34:48 +0900, Addison Phillips  
<addison.phillips@quest.com> wrote:

>
> 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 Thursday, 7 July 2005 01:31:03 UTC