[
https://issues.apache.org/jira/browse/SLING-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199332#comment-15199332
]
Joel Richard commented on SLING-5612:
-------------------------------------
[~bdelacretaz], [~rombert], the reason why I had to change this was because
with the Oak version update getProperty().getDate() started to return a
different time zone object which, however, represents the same time zone.
Therefore some tests failed. I wanted to keep the behaviour as close as
possible and therefore had to manually compare the time zone (the offset
instead of the object itself). I think this is the correct behaviour, but it
does not matter to me.
> AssertCalendar needlessly compares timezone offsets
> ---------------------------------------------------
>
> Key: SLING-5612
> URL: https://issues.apache.org/jira/browse/SLING-5612
> Project: Sling
> Issue Type: Bug
> Components: JCR
> Affects Versions: JCR Resource 2.7.4
> Reporter: Bertrand Delacretaz
> Assignee: Bertrand Delacretaz
> Priority: Minor
> Fix For: JCR Resource 2.8.0
>
>
> The {{AssertCalendar}} class in the test code compares Calendar objects like
> this:
> {code}
> assertEquals(expected.getTime(), actual.getTime());
> assertEquals(expected.getTimeZone().getRawOffset(),
> actual.getTimeZone().getRawOffset());
> {code}
> Comparing the timezones is not needed IMO, Calendar internally stores stores
> the time in msec since the epoch, so comparing getTimeInMillis() is
> sufficient to declare two Calendars as pointing to the same time. For our
> tests, it's fine for the timezones to be different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
