RE: date in user's timezone

> -----Original Message-----
> From: Ashok Malhotra/Watson/IBM [mailto:petsa@us.ibm.com]
> Sent: Thursday, October 26, 2000 2:20 PM
> To: Graham Ross
> Cc: www-xml-schema-comments@w3.org; Wm Aegerter
> Subject: Re: date in user's timezone
>
>
>
> Graham:
> Its not as bad as it seems!
> You should use the lexical representation that allows an optional
> time zone of your choosing.
>
> Here's the problem.  By using different timezones you can specify
> the same period of time in different ways. Some folks do not like
> this and want a single representation for specifying each unique
> value.  The canonical representation for dates, and similarly for other
> datatypes
> that have multiple lexical representations, anoints one of them as
> "canonical".  You don't have to use it.

I think I understand the idea. The idea is that every lexical representation
can be mapped to one and only one canonical representation.

I say there is no mapping from lexical to canonical.

In particular, there is no canonical representation for the "date"
consisting of the ISO 8601 period
    2000-10-26T00:00-07:00/P1D
A lexical representation for this value as an XSD date is
    2000-10-26-07:00
This is what a person here in Portland would call "today".

If there is a canonical representation for this date (presumably something
ending in "Z") please tell me what it is.

Apparently the six types date, month, year, century, recurringDate, and
recurringDay do not have time elements. They only have date elements. Only
the timezone part empowers these types to represent periods that begin at an
arbitrary time of day UTC. All canonical forms end in "Z" and appear to
begin and end at 17:00 local time here in Portland.

GR

>
> All the best, Ashok
>
>
> "Graham Ross" <gar@thinkshare.com>@w3.org on 10/26/2000 01:28:31 PM
>
> Sent by:  www-xml-schema-comments-request@w3.org
>
>
> To:   <www-xml-schema-comments@w3.org>
> cc:   "Wm Aegerter" <wca@thinkshare.com>
> Subject:  date in user's timezone
>
>
>
> Context: SML Schema Part 2: Datatypes, 24 Oct 2000, section 3.3.27, "date"
> et al.
>
> In the Canonical Representation section of the datatype "date"
> the timezone
> is constrained to UTC.
>
> I think this is a copy/paste error.
>
> In my timezone (today it is Pacific Daylight Time) a date, as described,
> would represent the period from 5 p.m. on the preceding day to 5 p.m. on
> the
> day named. It is hard to make a case for this datatype.
>
> The objection is germane also to month, year, century, recurringDate, and
> recurringDay. Similar wording for time, timeInstant, etc. is apparently OK
> as written because the time elements are explicit.
>
> If the date et al. wording is intended as written, it means that
> no lexical
> representation can represent the midnight-to-midnight period in another
> timezone. This makes date less useful, but, more pertinent to the task of
> writing the specification, it begs for more explanation in the Lexical
> Representation section. It becomes necessary to explain what it
> means for a
> lexical representation to specify a timezone other than UTC. For example,
> it
> might determine which Greenwich day is actually intended.
>
> Graham Ross
> ThinkShare Corp.
> Portland, Oregon
> gar@thinkshare.com
>
>
>
>
>

Received on Thursday, 26 October 2000 18:10:50 UTC