- 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