[
https://issues.apache.org/jira/browse/OAK-1111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803031#comment-13803031
]
Jukka Zitting commented on OAK-1111:
------------------------------------
bq. this will both increase the storage size and conversion times
It does, but AFAICT not considerably.
The size overhead is about 20 bytes per value, which isn't much given that the
vast majority of nodes (see http://markmail.org/message/kxe3iy2hnodxsghe)
contain at most a single date property. The SegmentMK is so far the only
backend that has put serious effort into reducing the storage overhead, and
there we already store all non-binary properties as strings since the size
overhead is insignificant in all normal cases and still reasonable even in the
unlikely worst-case scenario of a large date array with no duplicate values.
The extra conversion time should also be insignificant in the big picture. It's
a microsecond-level operation that I can't imagine us doing often enough to
make any notable difference at the application level.
> Node#setProperty(String, Calendar) doesn't take time zone in account
> --------------------------------------------------------------------
>
> Key: OAK-1111
> URL: https://issues.apache.org/jira/browse/OAK-1111
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
> Reporter: Antonio Sanso
> Attachments: OAK-1111-test.txt
>
>
> Node#setProperty(String, Calendar) doesn't take time zone in account.
> It looks the Calendar value is straightly stored as a long without take in
> consideration the time zone,
> Unit test to follow
--
This message was sent by Atlassian JIRA
(v6.1#6144)
