Leap second validation

Appendix D says:

"A value of 60 or more is allowed only in the case of leap seconds.

Strictly speaking, a value of 60 or more is not sensible unless the month
and day could represent March 31, June 30, September 30, or December 31 in
UTC. Because the leap second is added or subtracted as the last second of
the day in UTC time, the long (or short) minute could occur at other times
in local time. In cases where the leap second is used with an inappropriate
month and day it, and any fractional seconds, should considered as added or
subtracted from the following minute."

Consider a dateTime like this:

 1970-01-01T09:30:60Z

This is completely bogus for a number of reasons (leap seconds only on last
day of March, June, September; leap second only on last second of day; no
leap second before 1972).  The last sentence above would seem to suggest
that this should be silently accepted and converted to 1970-01-01T09-31-01Z.
This surely cannot be right. That date is as bogus as a date that specifies
the 29th day of February in a year that is not a leap year.  It is very easy
to imagine an off-by-1 software bug that generates 60 instead of 59 in the
second field.  It cannot be right for a validator to accept and mangle it
into a different (but valid) date.

I think we can distinguish the following questions:

1. Assuming that an XML Schema processor encounters a leap second and
classifies it as (a) definitely valid (b) unsure or (c) definitely invalid,
what should it do in each case?  I would argue in case (c) it should give an
error and in case (a) or (b) it should allow it.

2. What algorithm is the XML Schema processor supposed to use for
classifying a leap second as (a), (b) or (c)?  Each of the following is a
piece of knowledge that an XML Schema processor could apply:

(a) No leap seconds occurred before 1971-12-31
(b) All leap seconds that have occurred so far have occurred on 31st
December or 30th June.
(c) Leap seconds only occur on 31st March, 30th June, 30th September, or
31st December (in GMT)
(d) Leap seconds only occur on the last second of the day.
(e) The leap seconds that occurred so far are: 1971-12-31,...,1998-12-31
(f) There will be no leap second on 2002-06-30.
(g) The next potential leap second is 2002-12-31 (or maybe 2002-09-30).

Which of the above is an XML Schema processor expected to apply in
validating a leap second?

3. How should future leap seconds be handled?  For example, what if a
processor running today encounters the date 2010-12-31T23:59:60Z?  Now it's
possible that at some future point this will be declared to be a leap
second.  But at the moment, we know for certain that it has not been decided
whether it should be a leap second.  Given this, should a user get an error
if today they feed 2010-12-31T23:59:60Z to an XML Schema processor?

4. How should leap seconds in a time value with a time zone be handled?  I
guess it should be rejected if it does not correspond to 23:59:60Z. But what
recurring instant of time would this denote? Every leap second?

5. How should leap seconds in a time value without a time zone be handled?
Because of time zones, I guess anything is OK.

6. How should leap seconds in a dateTime value without a time zone be
handled? By analogy with 3.2.7.3, one approach might be to say that a
dateTime P without a time zone is valid if and only if there is a time zone
T where -14:00 <= T <= 14:00 such that PT is valid.

It's very unclear to me what the right thing to do is here.  This whole
thing makes my head spin.  However, I think the spec needs to say a lot more
if interoperability wrt leap seconds is to be achieved.

James

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