[
https://issues.apache.org/jira/browse/JCR-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861397#action_12861397
]
Alexander Klimetschek commented on JCR-2619:
--------------------------------------------
> If we only want to support possible values according to the JCR 2.0
> specification (this I'm not sure)
That's what I actually meant.
Most notably, JCR 1.0 and 2.0 specifies the date based on the iso8601 string
representation without the timezone ID, only with the current offset. Hence
including the timezone ID and thus potentially changing the date upon access
because of the re-interpretation of the rules and thus a different offset,
could break existing applications that currently must work around this issue by
storing the timezone ID separately.
(It would be nice to have the timezone ID included, of course, but the spec
unfortunately did not get this 100% right.)
> for example in the format yyyymmddhhMMssMMMZZZZ
Might work. ZZZZ would probably be shifted into the positive region, eg. by
adding -900 if we say -900 is the smallest negative timezone offset in minutes.
> improved internal representation of DATE values
> -----------------------------------------------
>
> Key: JCR-2619
> URL: https://issues.apache.org/jira/browse/JCR-2619
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core, jackrabbit-spi-commons
> Reporter: Stefan Guggisberg
> Priority: Minor
> Fix For: 2.2.0
>
> Attachments:
> JCR-2619_improved_internal_representation_of_DATE_values.patch
>
>
> DATE values are currently internally represented as java.util.Calendar
> objects.
> Calendar objects have a huge memory footprint (approx 200bytes per instance)
> and are mutable.
> i suggest to replace the internal DATE representation with a ISO8601 format
> string
> (immutable and approx. 85-90% smaller footprint).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
