[Bug 2136] R-145: Leap second validation

http://www.w3.org/Bugs/Public/show_bug.cgi?id=2136

           Summary: R-145: Leap second validation
           Product: XML Schema
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSD Part 2: Datatypes
        AssignedTo: cmsmcq@w3.org
        ReportedBy: sandygao@ca.ibm.com
         QAContact: www-xml-schema-comments@w3.org


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:

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

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? 
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? 
How should leap seconds in a time value without a time zone be handled? Because 
of time zones, I guess anything is OK. 
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.

See:
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0047.html

Received on Monday, 12 September 2005 15:11:23 UTC