This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A number of problems with these new date/time tests. date-094j says 0400-02-29 is invalid because 0400 is not a leap year. Wrong, it is a leap year. date-094m says -0400-02-29 is valid because -0400 is a leap year. This depends on whether there is a year 0, which depends on whether you follow XSD 1.0 or XSD 1.1 date-094n also depends on year 0 therefore choice of XSD version date-094o ditto date-094p uses a different date in the input from that expected in the output date-094q claims 0400 is not a leap year. Oh yes it is. date-095m - sane problem as date-094m date-095n - sane problem as date-094n date-095o - sane problem as date-094o
> date-094j says 0400-02-29 is invalid because 0400 is not a leap year. > Wrong, it is a leap year. and > date-094q claims 0400 is not a leap year. Oh yes it is. Indeed, copy/paste error. Fixed. > date-094m says -0400-02-29 is valid because -0400 is a leap year. > This depends on whether there is a year 0, which depends on whether you > follow XSD 1.0 or XSD 1.1 and > date-094n also depends on year 0 therefore choice of XSD version and > date-094o ditto and > date-095m - sane problem as date-094m and > date-095n - sane problem as date-094n and > date-095o - sane problem as date-094o For all these tests, there is a dependency element specified: <year_component_values satisfied="true" value="support year zero"/> This dependency implies XSD 1.1 rules (though I believe the spec made support for the year zero optional, which is why this feature element is required). It was missing on date-094m and date-095m, added there. > date-094p uses a different date in the input from that expected in the output Was fixed a few weeks ago, but not notified here.
Changes pushed in Hg repository.
Was resolved > 30 days ago, closing.