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.

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 17:20:55 UTC