dateTime order relation and leap seconds

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).

James

Received on Wednesday, 24 April 2002 00:49:42 UTC