[
https://issues.apache.org/jira/browse/OAK-1111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803920#comment-13803920
]
Thomas Mueller commented on OAK-1111:
-------------------------------------
We need to ensure that if you open a repository in a different timezone, that
the stored times are different. Therefore, we can't just store the UTC time. We
need to store time+timezone, or local time. I'm not sure if storing just the
local time is spec compliant, even thought the timezone was not important for
99% of all uses cases I saw.
> BundleWriter#writeDate() as it's a compact and fast way
It uses java.util.Calendar, which I would try to avoid, at least internally
(for the JCR API we have to support it, but I would avoid it within oak-core as
much as possible). I have seen quite many problems with java.util.Calendar, for
example [1] (I logged that bug, and it took over 2 years to resolve). It is
slow, daylight saving boundaries are problematic, timezones are problematic.
There will be a different API in future versions of Java.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6772689
> 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)
