From: James Clark <jjc@jclark.com>

Date: Wed, 24 Apr 2002 11:49:35 +0700

Message-ID: <004d01c1eb4b$7010ac60$3500a8c0@bkk.thaiopensource.com>

To: "XML Schema Comments" <www-xml-schema-comments@w3.org>

Date: Wed, 24 Apr 2002 11:49:35 +0700

Message-ID: <004d01c1eb4b$7010ac60$3500a8c0@bkk.thaiopensource.com>

To: "XML Schema Comments" <www-xml-schema-comments@w3.org>

Consider the dateTime of the last leap second: 1998-12-31T23:59:60Z (P) This instant in time can also have the lexical representation of, for example, 1998-12-31T22:59:60-01:00 (Q) Section 3.2.7.3 defines the algoritm for comparing two dateTimes as follows: "A.Normalize P and Q. That is, if there is a timezone present, but it is not Z, convert it to Z using the addition operation defined in Adding durations to dateTimes (§E)" Now in our example P has a Z timezone, but Q doesn't, so we need to normalize Q to Z using Appendix E. But E.1 says: "Leap seconds are handled by the computation by treating them as overflows. Essentially, a value of 60 seconds in S is treated as if it were a duration of 60 seconds added to S (with a zero seconds field). All calculations thereafter use 60 seconds per minute." This implies that Q is first mapped into: 1998-12-31T23:00:00-01:00 Then following the rest of algorithm in Appendix E, this will map into: 1999-01-01T00:00:00Z Now comparing: 1998-12-31T23:59:60Z and 1999-01-01T00:00:00Z we find that P < Q But P and Q represent the same value. So we have a contradiction: two lexical representations represent the same value, but the value represented by one lexical representation is less than the value represented by the other lexical representation. How can this be fixed? I hope it would be an uncontroversial proposition that the order relation on dateTime (where either both or neither dateTimes have a time zone) should be the natural one, that is one dateTime should be before another if and only if the instant of time represented by the one precedes the instant of time represented by the other. This means that it cannot be correct to map: 1998-12-31T22:59:60-01:00 to 1998-12-31T23:00:00-01:00 as part of the algorithm for normalizing the time zone, since these represent different instants in time. Thus 3.2.7.3 should either say something like: "convert it to a dateTime representing the same instant of time but using time zone Z" or "convert it to Z as follows: save the seconds field; set the seconds to zero; convert to Z using the addition operation in E; set the seconds field to the saved value" The above is a temporary band-aid; a proper fix is to distinguish between (a) the conversion from the lexical space and the value space (b) comparison between two values in the value space Normalizing the time-zone (if present) to Z is part of (a). If I have understood correctly, the value space of dateTime can be considered to be a 7-tuple: <Y, M, D, h, m, s, Z> where Y is an integer M is an integer between 1 and 12 ... s is a decimal greater or equal to 0 and strictly less that 61 Z is a boolean flag (indicating whether a time zone was specified). The conversion (a) must preserve leap-seconds. The comparison (b) is a comparison on *value* spaces and thus should not specify the normalization of any time zone to Z since that is done as part of (a). JamesReceived on Wednesday, 24 April 2002 00:49:42 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 23:08:58 UTC
*