RE: date in user's timezone

Hi Noah, Paul, and Ashok,

Not sure who "you" is meant to be in the first line of Noah's enclosed post
("The point you may be missing").

If it is not me (Graham) then please disregard this post.

Otherwise, I think there has been a misunderstanding. The type "time" is
fine. The problems are with date, month, year, century, recurringDate, and
recurringDay.

The treatment of "date" in the 24 October spec says,

"3.3.27.1 Lexical representation
The lexical representation for date is the reduced (right truncated) lexical
representation for timePeriod: CCYY-MM-DD. No left truncation is allowed. An
optional following time zone qualifier is allowed as for timePeriod. To
accommodate year values outside the range from 0001 to 9999, additional
digits can be added to the left of this representation and a preceding '-'
is allowed."

I understood "optional following time zone qualifier" to mean an optional
following time zone qualifier. Perhaps that was wrong. :-)

Again, I simply ask to be shown the canonical representation of the date
value denoted by the lexical representation:
   2000-10-26-07:00
This is the date that begins and ends at midnight on either end of the day
26 October 2000, Pacific Daylight Time. If I'm confused this ought to be a
simple task. (On the other hand, I could never get a canonical date in
college, and I don't know why I would be any luckier now.)

Thanks

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 16:57:37 UTC