Re: Date

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 09:58:21 UTC