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

(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: www-i18n-comments-request@w3.org [mailto:www-i18n-comments-
> request@w3.org] On Behalf Of C. M. Sperberg-McQueen
> Sent: Monday, August 04, 2008 4:45 PM
> To: www-i18n-comments@w3.org
> 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

Received on Tuesday, 5 August 2008 00:06:10 UTC