- From: <bugzilla@jessica.w3.org>
- Date: Mon, 30 Mar 2015 20:21:21 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27336 Abel Braaksma <abel.braaksma@xs4all.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |abel.braaksma@xs4all.nl Resolution|--- |FIXED --- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> --- > 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 30 March 2015 20:21:24 UTC