This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following tests for fn:parse-ietf-date may need to be fixed (maybe, the F&O 3.1 spec needs to be updated instead): * parse-ietf-date-15 Test environment: <param name="d" as="xs:dateTime" select="xs:dateTime('2014-08-20T19:36:01Z')"/> Correct: <param name="d" as="xs:dateTime" select="xs:dateTime('2014-09-09T19:36:01Z')"/> * parse-ietf-date-16 Test string: ... "Tue, 9 Sep 2014 19:36:01 GMT" ... Grammar in XQ31 F&O spec only allows single spaces (S?). * parse-ietf-date-19 Test string: ... "Aug-20-2014 19:36" ... Conflicts with the spec: input ::= ... (datespec S time) | asctime ... datespec ::= daynum dsep monthname dsep year asctime ::= monthname dsep daynum S time S year * parse-ietf-date-20, parse-ietf-date-21, parse-ietf-date-22, parse-ietf-date-23 Conflicts with the spec (see above). * parse-ietf-date-errs9 Test string: ... "Fri, 28 Feb -2000 19:36:01 GMT" ... Is correct, according to the grammar in the spec.
Liam, could you comment on this please?
I'll look into it today. At least one is a typo resulting from not having an implementation to test the tests :-)
[left open because we should consider changing the grammar] * parse-ietf-date-15 fixed, thanks! On whitespace, the description says, Accepts one or more whitespace characters (x20, x09, x0A, x0D) wherever a single space is required Probably the grammar should use a + in the definition of S; the grammars I merged to get here were rather imprecise about such things, unfortunately. * parse-ietf-date-19 fixed, thanks! * parse-ietf-date-20, parse-ietf-date-21, parse-ietf-date-22, parse-ietf-date-23 fixed (same error) * parse-ietf-date-errs9 Hah you're right, the - is taken as a separator. Fixed; the new version should I think be an error. You can't actually get a negative year in there by the grammar, of course, so unless an implementor tried to cheat by using a parsedate() library function and forgot to test for this case it seems unlikely. Thanks for the report!
Actually I opened bug 27338 and will close this one as the tests I think are fixed. Christian, if you find I still have errors, feel free to reopen! Thanks!
All tests are now passing.. Except for one: * parse-ietf-date-16 Similar to parse-ietf-date-15 (see my initial comment), the date in the test and the input is different and needs to be aligned.
Sorry, there are two more: parse-ietf-date-19 and parse-ietf-date-20 still need to be fixed (see my initial comment).
Fixed. I actually wonder if we should allow a hyphen as well as a space in more places; I made the grammar by combining the ones in the various specs cited, choosing the more flexible rule when there were conflicts. I'd need to check it didn't introduce an ambiguity but I don't think so. I've marked this as resolved fixed, feel free to reopen if I failed again :-) (and to open a new bug if you feel we should change the grammar) Thanks!
Hi Liam, the date strings in query 19 and 20... "Aug-20 2014 19:36" ...still don't comply with the spec. The (currently) expected format is: asctime ::= monthname dsep daynum S time S year In short, time and year need to be swapped.
Hmm, I'll leave this open, please close if I got it right :-)
Looks good! Thanks.