[
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.
