W3C home > Mailing lists > Public > public-qt-comments@w3.org > March 2015

[Bug 27336] date-094 and date-095 test family

From: <bugzilla@jessica.w3.org>
Date: Mon, 30 Mar 2015 20:21:21 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-27336-523-HMpnyvRc77@http.www.w3.org/Bugs/Public/>

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.

> 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

> date-094n also depends on year 0 therefore choice of XSD version

> date-094o ditto

> date-095m - sane problem as date-094m

> date-095n - sane problem as date-094n

> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:53 UTC