This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This test reads: <test-case name="parse-ietf-date-6"> <description>long fractional seconds</description> <created by="Liam R E Quin" on="2014-08-22"/> <!--* XSD implementations must support milliseconds in dateTime objects. * We don't specify whether parse-ietf-date() must do the same, but * since it returns a dateTime object that seems a resonable * interpretation. Greater precisions is permitted. Hwere all we care * about is that it's not an error and that the rounding is the same * in both cases. *--> <environment> <param name="d" as="xs:dateTime" select="xs:dateTime('2014-08-20T19:36:01.2999999999999999999999999999999Z')"/> </environment> <test>if (parse-ietf-date("Wed, 20 Aug 2014 19:36:01.2999999999999999999999999999999 GMT") = $d) then "pass" else "fail"</test> <result> <assert-string-value>pass</assert-string-value> </result> </test-case> Implementations are only required to support three digits of fractional seconds, and the effect when you supply more than this isn't well defined in the spec. At the very least, we shouldn't do it without a dependency. Furthermore, things that are processor-dependent should never be defined except in the query-under-test, because it's assumed that all the metadata can be processed in order to determine the test dependencies. So as a first step in fixing this I'm going to move the questionable cast operation into the query.
I've reduced the precision to 3 digits; we don't need (in this test suite) to test implementation-dependent precision.