Discussion of XML Schema data/time (fwd from xmlschema-dev)

This discussion seems particularly relevant to www-rdf-calendar; see
http://lists.w3.org/Archives/Public/xmlschema-dev/
http://lists.w3.org/Archives/Public/xmlschema-dev/2001Jul/0072.html for
hyperlinked thread.

Dan

---------- Forwarded message ----------
Date: 07 Jul 2001 14:58:23 +0100
From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
To: Noah_Mendelsohn@lotus.com
Cc: Jeff Rafter <jeffrafter@definedweb.com>, vdv@dyomedea.com,
     xmlschema-dev@w3.org
Subject: Re: Date
Resent-Date: Sat, 7 Jul 2001 09:58:39 -0400 (EDT)
Resent-From: xmlschema-dev@w3.org

Noah_Mendelsohn@lotus.com writes:

> Jeff Rafter writes:
>
> >> does this mean that an optional Time Zone Qualifier
> >> should be added
>
> Not sure, but there is some background that may be of interest.  First,
> many readers fail to recognize that in XML Schema Datatypes, timezone
> indicators are in the lexical representations only.

Not true, as I understand it/read the REC [1].  The value space of
time (and dateTime) consists of _two_ sets, each totally ordered, but
only partially ordered wrt one another.  The first is the set of
timezone-free, or local, times, the second the set of
timezone-specific times.

> Their status is similar to leading zeros, or exponential notations
> (1E+2) vs.  unnormalized floats (100.0); timezones are visible, but
> not considered to affect the value of the time or integer
> respectively.

This is just not true.  12:00:00 is not equal to 12:00:00Z.  What _is_
true is that the various timezone-specific ways of specifying a time
_are_ equal, e.g. 12:00:00Z is equal to 13:00:00Z+1.

> The times themselves are all effectively converted to a fixed UTC
> form for comparison or other use as values.

Only for timezone-specific times -- not for local times.

> This also has the interesting effect that two different times in
> different timezones can be considered equal for purposes of
> enumeration, as are the two floats above.

So you think 12:00:00Z should correspond to a different point in the
value space than 13:00:00Z+1?

> I argued against this design for timezones in particular, as I think
> it violates least-astonishment for users, but there it is.

Speaking as someone who regularly has to deal with this in calendaring
applications, I have the opposite stance -- I'd be very irritated if
my calender _didn't_ beep at 12:00:00Z if I have an appointment set up
be a colleague in France for 13:00:00Z+1!

> I believe that users consider timezones more significant than
> leading zeros.  No matter, that is the starting point for any future
> evolution.  I would have preferred to allow no timezone at all than
> one that has such minimal effect on semantics and comparison.
>
> Also, Lotus (my employer) has some experience building timezone-aware
> applications.   Turns out we have had bugs reported, in calendaring
> applications for example, that were caused by political rather than
> technical actions.   A user schedules a meeting at 3PM in GMT-6, but they
> really think they're scheduling it in Chicago.  Chicago changes its laws,
> and the calander rings the alarm too early or late...it is indeed GMT-6,
> but it's no longer 3PM in Chicago.  These are real bugs from real users.

_That_'s a bug wrt the semantics of Z-6, not about the equivalence
case discussed above, isn't it?

ht


[1] http://www.w3.org/TR/xmlschema-2/#time
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Saturday, 7 July 2001 10:21:23 UTC