Patch submitted: https://sourceforge.net/p/ical4j/patches/81/
Why did the issue only occur on Android and not on my PC, running OpenJDK?
The DateParser of my OpenJDK 1.7.0 seems to call TimeZone.getOffset(long)
when a timezone is passed, while Android’s Java seems to call TimeZone.getOffset(era,y,m,d,dow,ms)
. Only the latter one has bugs in the net.fortuna.ical4j.model.TimeZone
implementation, so this is why only Android is effected.
Why does the error depend on the local device clock?
Calendar.DAY_OF_YEAR
is set instead of DAY_OF_MONTH
, so DAY_OF_MONTH
is set to the current day of month, leading to test results depending on the local date. So, when evaluating “20140302T080000” on 28.2.2014 the created calendar had these properties:
ERA: AD
YEAR: 2014
MONTH: 3 # instead of 2, meaning April
DAY_OF_MONTH: <day of year of current time> == 28
So, the time zone offset was evaluated for 28.4. instead of 2.3., and on 28.4. there’s already daylight saving → 2h time offset instead of one. So, these times got effectively shifted by one hour.
I’m happy that I was able to find out the reasons for this issue because it’s really weird that it
- only happend when syncing new events on certain dates
- can be seen only on Android
Closing this because it’s a third-party bug and the patch is submitted. I will use a new version of the ical4j library as soon as it’s available (hopefully soon).
11 working hours were needed to resolve this issue.