RE: date in user's timezone

Dear Noah, Paul, and Ashok,

Here is a proposed amendment. This is for "date". Similar changes must be
made in month, year, century, recurringDate, and recurringDay.


Old way:


3.3.27.2 Canonical representation
The canonical representation for date is defined by prohibiting certain
options from the Lexical representation (?3.3.27.1). Specifically, the
preceding optional "+" sign is prohibited and the time zone must be
Coordinated Universal Time (UTC) and be indicated by a "Z".


New way:


3.3.27.2 Canonical representation
The canonical representation for date is defined by prohibiting certain
options from the Lexical representation (?3.3.27.1). Specifically, the
preceding optional "+" sign is prohibited and the time zone must immediately
follow the time and consist of a sign, + or -, followed by hh:mm. If the
timezone is Coordinated Universal Time (UTC) it must be indicated by a "Z"
instead.


Respectfully submitted,

Graham Ross
ThinkShare Corp.
Portland, Oregon


> -----Original Message-----
> From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
> Sent: Friday, October 27, 2000 1:09 PM
> To: Graham Ross
> Cc: petsa@us.ibm.com; wca@thinkshare.com; www-xml-schema-comments@w3.org
> Subject: RE: date in user's timezone
>
>
> The point you may be missing is that, for better or worse, the time zone
> is not included in the value space of the time type (right Paul & Ashok?
> it's not in 8601 section 5.4 and its not in Datatypes section 3.2.6, both
> of which are referenced in defining value spaces for date-related types).
> Think about it this way: 10.0 and 1.0E+1 are the _same_ float,
> represented
> differently.  Nothing in the value space allows you to distinguish one
> from the other.  In that respect, the lexical representations are
> primarily a convenience, although we could certainly burn a lot of energy
> debating the degree to which applications should attempt to derive useful
> information from the differences between these two.
>
> In the same spirit, the time 1999-05-31T13:20:00.000-05:00 and
> 1999-05-31T18:20:00.000 _are_ the same time.  The datatype signals no
> semantic differences between the two, just as with the floating point
> example above.  The number (-5) does not appear in the value
> space for the
> first form.
>
> Now, I say for better or worse because one can certainly imagine
> situations in which you would like to do computation on the time
> zone.  It
> is also the case that dealing with time zones at all is known to be quite
> subtle business (Our company has actually had bugs reported in our
> calendar system such as: users scheduled appointments far in advance, and
> legislatures enacted new timezone laws between the scheduling of the
> appointment and the appointment itself.  The alarm rings an hour late.)
> When scheduling is done across political and geographic boundaries, this
> all gets very difficult.  My own preference would have been to leave the
> time zone specification out of the schema datatype entirely, and require
> that all times be explicitly UTC, because it would be clearer that the
> timezone has no semantic significance.  Nonetheless, it is obviously a
> convenience to be able to use the +/- zone notation in systems where time
> zones are stable and users wish to encode local times.
>
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------
>
>
>
>

Received on Friday, 27 October 2000 17:23:34 UTC