Wrong start time
Still investigating in iCal4j source…
// tz = fortuna.VTimeZone Europe/Vienna // always correct on Android/PC DateTime date = new DateTime("20140302T080000"); date.setTimeZone(tz); // should be the same, but is different on Android on some (Sun?)days only: DateTime date = new DateTime("20140302T080000", tz);
Ok, it’s an iCal4j bug:
final DateFormat format = new SimpleDateFormat("yyyyMMdd'T'HHmmss"); format.setTimeZone(java.util.TimeZone.getDefault()); Date date = format.parse("20140302T080000");
TimeZone tz = DefaultTimeZoneRegistryFactory.getInstance().createRegistry().getTimeZone("Europe/Vienna") final DateFormat format = new SimpleDateFormat("yyyyMMdd'T'HHmmss"); format.setTimeZone(tz); Date date = format.parse("20140302T080000");
does not (although the system’s default time zone is Europe/Vienna); so there’s some difference between
net.fortuna.ical4j.model.TimeZone(Europe/Vienna) although the latter is a subclass of the first one;
where “doesn’t work” means: doesn’t work on Android and on certain system dates (works on my PC and on other local dates).
So now I know that’s a ical4j issue, but I think I’ll still do more investigation so that I can provide a useful bug report to ical4j.
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.TimeZoneimplementation, so this is why only Android is effected.
Why does the error depend on the local device clock?
Calendar.DAY_OF_YEARis set instead of
DAY_OF_MONTHis 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.
Thank you very much
Patch for iCal4j is available here: https://github.com/ical4j/ical4j/pull/14
AutoImport-newluck77 last edited by
I just wanted to ask, if the patch has been already implemented because I am still experiencing the problem. (Now it occurs on Oct. 4 and 5.)
It has been merged into the ical4j 1.4-maintenance branch but not into the master branch. Also, as far as I have seen, there was no new ical4j release until yet but @benfortuna is active on the branches. Maybe you can find out when a new release is planned?
AutoImport-benfortuna last edited by
I have merged the change into ical4j master now. Hopefully there will be another official alpha release for ical4j 2.0 soon, but in the meantime use the automated snapshot builds found here:
@benfortuna Thanks for the info. When using the latest master snapshot, I get a
ClassCastException: XComponent cannot be cast to VEVentwhen I do
(VEvent)ical.getComponent(Component.VEVENT). Would it be possible to provide a single snapshot of the 1.0.x series until 2.0 is ready for release? I tried to build it but failed and I guess it’s much less work for you.
AutoImport-jorisvandesande last edited by
I’m also experiencing this bug (or at least something that looks like it). This morning daylight saving times have started here (in the Netherlands). And now all appointments start one hour earlier on my android device, compared to my owncloud web interface and Thunderbird.
This bug is so annoying that I have to uninstall Davdroid and search for another app
AutoImport-benfortuna last edited by
@rfc2822 the 1.0.x snapshot builds are also available on sonatype here:
Do you have a sample input file to reproduce the ClassCastException on master?
AutoImport-basc last edited by
Same here. Cause you don’t know on which day the time is displayed correct you cannot rely on the start time anymore.
Like Davdroid very much but with this bug it is unusable.
Can’t wait to see a ical4j build having that bug fixed.
Same here. Since I use DAVdroid myself, I always fear that (non-all-day) events may be one hour wrong.
@benfortuna The files in https://oss.sonatype.org/content/repositories/snapshots/org/mnode/ical4j/ical4j/1.0.6-SNAPSHOT/ are from 15 Jul 2014 and don’t contain my patch yet (it neither works nor can I see my changes in the sources.jar). Are there more recent snapshots (maybe daily builds) available that include the patch for the timezone problem?
For the records: when I today (27 Oct 2014) sync an event on 2 Mar 2014, times are one hour wrong.
Until the bug is fixed I will use CalDAV Sync Free Beta
@ScreenDriver Maybe you can help fixing it by compiling a recent ical4j jar? By the way, CalDavSync Free Beta seems to use iCal4j, too, so I guess that won’t help.
CalDavSync Free Beta uses iCal4j? Really? Hmm then there is something different to DavDroid because it displayes the correct time on my device.
@ScreenDriver You know that this bug only occurs in rare conditions? Did you try to sync exactly the same event at the same device clock day/time (not event time, clock time on your device) with different results?
However, I have now managed to build ical4j 1.0.6 with maven without problems and can confirm that this bug is now fixed. I’ll release a new DAVdroid version very soon.