You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Andrey Adamovich (JIRA)" <ji...@apache.org> on 2008/02/14 15:27:12 UTC
[jira] Created: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
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: Bug
Components: jackrabbit-jcr-commons, xml
Affects Versions: 1.4
Reporter: Andrey Adamovich
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.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.
[jira] Updated: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
Posted by "Andrey Adamovich (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrey Adamovich updated JCR-1386:
----------------------------------
Attachment: ISO8601Test.java
Also i have created a JUnit4 test case to test for valid dates.
> 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: Bug
> Components: jackrabbit-jcr-commons, xml
> Affects Versions: 1.4
> Reporter: Andrey Adamovich
> Attachments: 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.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.
[jira] Updated: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
Posted by "Andrey Adamovich (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrey Adamovich updated JCR-1386:
----------------------------------
Attachment: ImportDateHandling.patch
Here is new patch. I have tried to preserve original formatting as much as possible. As to the logic I have introduced new method in ISO8601 class called relaxedParse. This method is only now used in StringValue and BufferedStringValue in order to adapt imported dates to JCR strict format.
I wait your comments impatiently and it would be really good for my project if this patch would be included in some of the following jackrabbit releases (as it causes our import functionality to fail because of the fact that XML Schema has more relaxed date format definition). Any chances for that Jukka?
If you see that this patch can be improved in some way, just tell me how and I will do that.
> 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.
[jira] Commented: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657328#action_12657328 ]
Stefan Guggisberg commented on JCR-1386:
----------------------------------------
-1 for System View Import accepting non-spec compliant date formats.
it's not clear how an incomplete date value should be properly expanded
(e.g. missing time zone, assume Zulu or current TZ?). the result of
a System View Import would become somehow unpredictable.
however, i wouldn't be opposed to adding conveniance methods to ISO8601.
> 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.
[jira] Updated: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
Posted by "Andrey Adamovich (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrey Adamovich updated JCR-1386:
----------------------------------
Attachment: ISO8601.java.patch
I have created a patch that is more liberal in parsing dates and allows formats specified above.
> 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: Bug
> Components: jackrabbit-jcr-commons, xml
> Affects Versions: 1.4
> Reporter: Andrey Adamovich
> Attachments: ISO8601.java.patch
>
>
> 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.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.
[jira] Commented: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568951#action_12568951 ]
Jukka Zitting commented on JCR-1386:
------------------------------------
Note that the date format implemented in the ISO8601 class is the strict ISO8601 subset described in the JCR standard. Relaxing that might be a good idea for many places, but it would probably be better to add a separate method for that so we can evaluate case-by-case whether using a liberal date parser is OK.
Another issue, your patch mixes formatting, structural, and functional changes. For example you've switched to using a StringTokenizer in the parser, which might be a good idea, but which makes it necessary to review not only the changes to relax the date parsing, but the entire new parsing mechanism. It would be nicer if you only included functional changes here, and submitted ideas for improved formatting and code structure in a separate improvement issue.
> 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: Bug
> Components: jackrabbit-jcr-commons, xml
> Affects Versions: 1.4
> Reporter: Andrey Adamovich
> Attachments: 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.
[jira] Issue Comment Edited: (JCR-1386) Not full parsing of ISO8601
date/time format that may cause import of XML to fail
Posted by "Andrey Adamovich (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568946#action_12568946 ]
superfilin edited comment on JCR-1386 at 2/14/08 6:29 AM:
----------------------------------------------------------------
I have identified that problem was in ISO8601.java and I have created a patch that is more liberal in parsing dates and allows formats specified above.
was (Author: superfilin):
I have created a patch that is more liberal in parsing dates and allows formats specified above.
> 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: Bug
> Components: jackrabbit-jcr-commons, xml
> Affects Versions: 1.4
> Reporter: Andrey Adamovich
> Attachments: 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.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.
[jira] Issue Comment Edited: (JCR-1386) Not full parsing of ISO8601
date/time format that may cause import of XML to fail
Posted by "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.
[jira] Updated: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Guggisberg updated JCR-1386:
-----------------------------------
Priority: Minor (was: Major)
Issue Type: New Feature (was: Bug)
not a bug, qualifying as 'new feature' instead.
the date serialization format used in JSR 170 is a clearly defined and
very specific variant of the large number of date/time formats described
by ISO 8601:2000.
please refer to section "6.2.5.1 Date" in the JSR 170 specification.
org.apache.jackrabbit.util.ISO8601 does exactly what is required by the
JSR 170 specification.
i am not sure whether accepting other ISO 8601-compliant date formats
in system view import would be legal according to the spec...
> 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: 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.
[jira] Commented: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
Posted by "Andrey Adamovich (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568948#action_12568948 ]
Andrey Adamovich commented on JCR-1386:
---------------------------------------
Also I noticed that ISO8601.java file is copied to several places in the repository.
\jackrabbit\contrib\tck-webapp\src\java\org\apache\jackrabbit\test\ISO8601.java
\jackrabbit\jackrabbit-jcr-commons\src\main\java\org\apache\jackrabbit\util\ISO8601.java
\jackrabbit\jackrabbit-jcr-tests\src\main\java\org\apache\jackrabbit\test\ISO8601.java
Is this intended?
> 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: Bug
> Components: jackrabbit-jcr-commons, xml
> Affects Versions: 1.4
> Reporter: Andrey Adamovich
> Attachments: 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.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.
[jira] Updated: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
Posted by "Andrey Adamovich (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrey Adamovich updated JCR-1386:
----------------------------------
Description:
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
was:
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.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
> 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: Bug
> Components: jackrabbit-jcr-commons, xml
> Affects Versions: 1.4
> Reporter: Andrey Adamovich
> Attachments: 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.
[jira] Commented: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
Posted by "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 commented on JCR-1386:
--------------------------------------------
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.
[jira] Commented: (JCR-1386) Not full parsing of ISO8601 date/time
format that may cause import of XML to fail
Posted by "Andrey Adamovich (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569002#action_12569002 ]
Andrey Adamovich commented on JCR-1386:
---------------------------------------
That was fast reply from you guys :).
Sorry, Jukka, I'm using IDE that has automatic formatting on file save, that probably changed the formatting. I will try to update the patch to be less intrusive, but I would definitely like to hear your opinion on the matter as I see now that problem is deeper than just ISO8601 class.
The reason I used StringTokenzier is that it makes programming for optional and custom length elements slightly easier than with just position in the string.
Thank you Stefan for your link to the specification, now I see why JR is supporting only that strict date format. However, it is arguable that it should support the same strict format during import. The reason for supporting wider date format could be that:
a) System View is an XML format.
b) There is a mapping defined in the spec. between XML types and JCR types. JCR Date <=> xs:dateTime.
c) According to xs:dateTime definition (you can check it with any validating XML parser) these values are valid dates:
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
but JR refuses to import those values.
But you are right it will probably be worth splitting the parsing functionality to support strict date format when date value is set through JCR API, or wider date format when data is imported from XML as XML has its own specification for date format.
Awaiting your comments on that.
> 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: 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.