- From: <Noah_Mendelsohn@lotus.com>
- Date: Fri, 27 Oct 2000 16:09:28 -0400
- To: "Graham Ross" <gar@thinkshare.com>
- Cc: petsa@us.ibm.com, wca@thinkshare.com, www-xml-schema-comments@w3.org
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:15:18 UTC