RE: Leap second validation

James:
I've been thinking about how to better specify leap second validation.
Here are some suggestions.  Please comment.  I discuss dateTime but this
applies to time as well.

The value space of dateTime is instants of time in timezone Z.  

1. For times in the past, we can specify exactly when leap seconds
occur.  If you use a timezone other than Z and specify a leap second
then, for the value to be valid, the dateTime translated to Z must
correspond to one of the legal dateTimes.

2. If you specify a dateTime in the past with a leap second but without
a timezone then it must be legal, as defined above, if it were given a
timezone of Z.

3. For dateTimes in the future we specify when leap seconds can occur
and consider values to be valid (leap seconds only on last day of March,
June, September; leap second only on last second of day;) if they meet
the given criteria.  This is both for dateTimes with and without
timezones as above.
  
The problem is that a value that validates today may become invalid a
few months from today.  I do not see a solution for this.

4. The sentence in 3.3.7.3 that 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."  Just seems to be a bug.  Your alternate wording
""convert it to a dateTime representing the same instant of time but
using time zone Z" seems to fix the problem but I want to think about
this a bit more.

All the best, Ashok 
===========================================================


-----Original Message-----
From: James Clark [mailto:jjc@jclark.com] 
Sent: Wednesday, April 24, 2002 12:01 AM
To: XML Schema Comments
Subject: 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 Tuesday, 28 May 2002 17:14:56 UTC