[Bug 26825] New: parse-ietf-date-6

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26825

            Bug ID: 26825
           Summary: parse-ietf-date-6
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3 & XPath 3 Test Suite
          Assignee: oneil@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 16 September 2014 22:02:57 UTC