[
https://issues.apache.org/jira/browse/OAK-1111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803219#comment-13803219
]
Jukka Zitting commented on OAK-1111:
------------------------------------
bq. BundleWriter#writeDate()
I think the exact storage format is best left to the storage engine. For
example the SegmentMK explicitly avoids multiple different value types so it
can better avoid duplicates. For example the amortized cost of storing the same
date value in 10 nodes is just about 6 bytes per value, compared to 8 bytes per
value used by the BundleWriter.
The main question here is whether we should keep the time zone information
around with date values. I recall early discussions where, partially because of
the limited data types in the JSON format used by the MicroKernel, we
considered that it would be OK to drop the time zone bits and simply store date
values as timestamps. So far we haven't run into cases where that would be a
problem, but perhaps here we have one.
> 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
> Priority: Critical
> 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)
