Comments on http://www.w3.org/TR/timezone/ of 13 October 2005

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Comments on http://www.w3.org/TR/timezone/ of 13 October 2005

C. M. Sperberg-McQueen

Thank you for this WG Note, to which Frans Englich recently called my
attention.  It is very helpful.

I have some comments.

(1) In section 1.2 "Identifying Time Zones and Zone Offsets", you write:

   As mentioned before, XML Schema only supports zone offsets ...
   So a wall time expressed as an XML Schema time value, must
   choose which zone offset to use.

This is true as far as it goes.  But unless I am missing something
crucial, it is a property not only of XML Schema but of every system
that uses ISO 8601 notation for dates and times.  As you point out
earlier in section 1.2, ISO 8601 representations can use time zone
offsets; unless I am missing something in my review of ISO 8601,  
however,
they do not provide for the use of representations of time zones, as
you define the term.

Perhaps I am over-sensitive here, but the passage quoted above seems to
me to be attributing XSD's reliance on time zone offsets (and the
difficulties that entails for descriptions of wall clock time) to a
decision made by the designers of XSD not to support time zones,
instead of to the decision made by the designers of XSD to support
ISO 8601 as the relevant international standard, and to achieve
compatibility with the timestamp datatypes of SQL.

I think the passage would be less misleading if it read "As mentioned
before, ISO 8601 and XML Schema only support ...".

(2) The passage quoted also seems, in the phrase "choose which zone
offset to use", to overlook the possibility of representing such
wall-clock times with structures like an offset-free xsd:time value
in one attribute or element and a code for the time zone (e.g. PT
or America/Los_Angeles or ...) in another.

(3) in section 1.4.1, the phrase

     a meeting that is always UTC-08:00 (and thus at 7:00 in the
     morning in Pacific time during parts of the year)

seems unclear to this reader.  What does it mean for a meeting to
"be UTC-08:00"?  I think you mean "a meeting that is always
scheduled for 08:00-08:00", but only you can say for certain.




Reply | Threaded
Open this post in threaded view
|

RE: Comments on http://www.w3.org/TR/timezone/ of 13 October 2005

Phillips, Addison
(personal comments follow; this thread copied to member-i18n-core@)

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [hidden email] [mailto:www-i18n-comments-
> [hidden email]] On Behalf Of C. M. Sperberg-McQueen
> Sent: Monday, August 04, 2008 4:45 PM
> To: [hidden email]
> Cc: C. M. Sperberg-McQueen
> Subject: Comments on http://www.w3.org/TR/timezone/ of 13 October
> 2005
>
>
> Thank you for this WG Note, to which Frans Englich recently called
> my
> attention.  It is very helpful.

Thanks. I find I cite it pretty often, albeit it needs more work.

>
> I have some comments.
>
> (1) In section 1.2 "Identifying Time Zones and Zone Offsets", you
> write:
>
>    As mentioned before, XML Schema only supports zone offsets ...
>    So a wall time expressed as an XML Schema time value, must
>    choose which zone offset to use.
>
> This is true as far as it goes.  But unless I am missing something
> crucial, it is a property not only of XML Schema but of every
> system
> that uses ISO 8601 notation for dates and times.

Yes. The point wasn't beat up on XML Schema per se. It was to make the point that zoneoffset != timezone (wherever it occurs). At the time, the use of schema data types was of particular interest (I forget why---something to do with Web services, I think).

I should point out that this particular Note is on our roadmap to be revised. Some of our working group (myself, Norbert, others) have amassed more experience/information in the meanwhile. Norbert in particular has a very nice document I'm hoping we can "steal" ;-).

> As you point out
> earlier in section 1.2, ISO 8601 representations can use time zone
> offsets; unless I am missing something in my review of ISO 8601,
> however,
> they do not provide for the use of representations of time zones,
> as
> you define the term.

Nope. ISO 8601 cannot convey a time zone (excepting UTC). Period. This is a constant source of pain in my day job too.

>
> Perhaps I am over-sensitive here, but the passage quoted above
> seems to
> me to be attributing XSD's reliance on time zone offsets (and the
> difficulties that entails for descriptions of wall clock time) to a
> decision made by the designers of XSD not to support time zones,
> instead of to the decision made by the designers of XSD to support
> ISO 8601 as the relevant international standard, and to achieve
> compatibility with the timestamp datatypes of SQL.
>
> I think the passage would be less misleading if it read "As
> mentioned
> before, ISO 8601 and XML Schema only support ...".

I should note that we did solicit and receive comments from the schema WG, particularly from Ashok, when this Note was originally written. We (the authors) understood the reasons for Schema's design decisions and any negative connotations were, I stress, not intentional--excepting to point out that zoneoffsets cannot do certain things.

>
> (2) The passage quoted also seems, in the phrase "choose which zone
> offset to use", to overlook the possibility of representing such
> wall-clock times with structures like an offset-free xsd:time value
> in one attribute or element and a code for the time zone (e.g. PT
> or America/Los_Angeles or ...) in another.

That is, of course, a possibility. The point we should be making here is that you need a *structure* if you need actual time zone operations. I should point out that most applications don't need time zones at all. One of the revision points would be to enumerate the use cases. It's more useful to say "if (situation x) do (y)" than merely say "xs:date doesn't work for this".

>
> (3) in section 1.4.1, the phrase
>
>      a meeting that is always UTC-08:00 (and thus at 7:00 in the
>      morning in Pacific time during parts of the year)
>
> seems unclear to this reader.  What does it mean for a meeting to
> "be UTC-08:00"?  I think you mean "a meeting that is always
> scheduled for 08:00-08:00", but only you can say for certain.
>

This is actually a scenario you should be familiar with from W3C: twice a year most of us move our teleconferences to account for daylight savings coming on/going off in various parts of the world. Since these aren't synchronized in time, we sometimes have a couple of weeks where the conference happens at the same universal time ("08:00-08:00"), but at a different wall time (Pacific time moves from 8 to 7, for instance). That's because Zakim doesn't change to Summer Time the same date as say London.

In any case, as we revise this document, I would welcome your personal comments and/or the comments of Schema and others.

Addison
Reply | Threaded
Open this post in threaded view
|

Re: Comments on http://www.w3.org/TR/timezone/ of 13 October 2005

C. M. Sperberg-McQueen

On 4 Aug 2008, at 18:05 , Phillips, Addison wrote:

> ...
> I should note that we did solicit and receive comments from the  
> schema WG, particularly from Ashok, when this Note was originally  
> written. We (the authors) understood the reasons for Schema's  
> design decisions and any negative connotations were, I stress, not  
> intentional--excepting to point out that zoneoffsets cannot do  
> certain things.

OK.  Point well taken.  I apologize for my hypersensitivity; mostly,
the public discussion of XSD has given me good opportunities to
develop a thick skin, but every now and then something gets  
through ... :)


>> (2) The passage quoted also seems, in the phrase "choose which zone
>> offset to use", to overlook the possibility of representing such
>> wall-clock times with structures like an offset-free xsd:time value
>> in one attribute or element and a code for the time zone (e.g. PT
>> or America/Los_Angeles or ...) in another.
>
> That is, of course, a possibility. The point we should be making  
> here is that you need a *structure* if you need actual time zone  
> operations. I should point out that most applications don't need  
> time zones at all. One of the revision points would be to enumerate  
> the use cases. It's more useful to say "if (situation x) do (y)"  
> than merely say "xs:date doesn't work for this".

Yes, I think that's true.

>
>>
>> (3) in section 1.4.1, the phrase
>>
>>      a meeting that is always UTC-08:00 (and thus at 7:00 in the
>>      morning in Pacific time during parts of the year)
>>
>> seems unclear to this reader.  What does it mean for a meeting to
>> "be UTC-08:00"?  I think you mean "a meeting that is always
>> scheduled for 08:00-08:00", but only you can say for certain.
>>
>
> This is actually a scenario you should be familiar with from W3C:  
> twice a year most of us move our teleconferences to account for  
> daylight savings coming on/going off in various parts of the world.  
> Since these aren't synchronized in time, we sometimes have a couple  
> of weeks where the conference happens at the same universal time  
> ("08:00-08:00"), but at a different wall time (Pacific time moves  
> from 8 to 7, for instance). That's because Zakim doesn't change to  
> Summer Time the same date as say London.

I am indeed familiar with that scenario; it's just that the sentence  
seems
to be phrased a little loosely.  A strict reading, or a reader who is  
having
trouble following the document, might object that a meeting can always
be scheduled at a particular clock time in a particular time zone (or
at a particular time zone offset), but it's as unusual to say that a  
meeting
is "always UTC-08:00" as it would be to invite you to attend a meeting
scheduled for Pacific Daylight Time, without mentioning a particular
time of day, in that time zone (or time zone offset).


best regards,

Michael Sperberg-McQueen