[jira] Issue Comment Edited: (JCR-1386) Not full parsing of ISO8601 date/time format that may cause import of XML to fail

["Alexander Klimetschek (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657137#action_12657137 ] 

alexander.klimetschek edited comment on JCR-1386 at 12/16/08 11:57 AM:
-----------------------------------------------------------------------

A support for relaxed ISO formats would be helpful, also for jcr queries, eg. "@jcr:lastModified < xs:dateTime('2008-12-18')" is simpler to remember and type than the full "@jcr:lastModified < xs:dateTime('2008-12-18T00:00:00.000Z')".

Since the spec is strict, I would only put it in places where the date is parsed, which would be the XML import and the XPath query parser. Allowing other values than the strict variant is not critical IMHO.

If we don't want to change that, it could also be helpful to have a ISO8601.toStrictFormat() method that will convert eg. '2008-12-18' => '2008-12-18T00:00:00.000Z', which would then be a utility function for users to call before they built the query string, for example.

      was (Author: alexander.klimetschek):
    A support for relaxed ISO formats would be helpful, also for jcr queries, eg. "@jcr:lastModified < xs:dateTime('2008-12-18')" is simpler to remember and type than the full "@jcr:lastModified < xs:dateTime('2008-12-18T00:00:00.000Z')".

Since the spec is strict, I would only put it in places where the date is parsed, which would be the XML import and the XPath query parser. Allowing other values than the default here is not critical IMHO.

If we don't want to change that, it could also be helpful to have a ISO8601.toStrictFormat() method that will convert eg. '2008-12-18' => '2008-12-18T00:00:00.000Z', which would then be a utility function for users to call before they built the query string, for example.
  
> Not full parsing of ISO8601 date/time format that may cause import of XML to fail
> ---------------------------------------------------------------------------------
>
>                 Key: JCR-1386
>                 URL: https://issues.apache.org/jira/browse/JCR-1386
>             Project: Jackrabbit
>          Issue Type: New Feature
>          Components: jackrabbit-jcr-commons, xml
>    Affects Versions: 1.4
>            Reporter: Andrey Adamovich
>            Priority: Minor
>         Attachments: ImportDateHandling.patch, ISO8601.java.patch, ISO8601Test.java
>
>
> Currently Jackrabbit allows only strict string values for date fields. The weak point is at handling milliseconds. JR allows only strictly 3 digits, but according to ISO8601 and to XML Schema data types definition milliseconds can be any number of digits and it just defines fractional part of the second.
> So, these are valid date strings which will not be validated by JackRabbit, but they are valid according to ISO8601 and also will be validated by XML Schema if selected data type is xs:dateTime:
> 2008-01-01T00:00:00
> 2008-01-01T00:00:00.0
> 2008-01-01T00:00:00.00
> 2008-01-01T00:00:00.1234
> 2008-01-01T00:00:00.1111111
> Another weak point is that time part is not mandatory as well according to ISO8601, so, these dates are also valid ISO8601 and also will be validated by XML Schema if selected data type is xs:date;
> 2008-01-01
> 2008-02-01
> 2008-03-01

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.