Wrong start time

---

I’ve found a very annoying bug: all my events that occurs on sundays have all a wrong time (-1 hour) on my android device. This bug is very easy to reproduce:

• open a CalDav application on your Desktop. E.g. Thunderbird. Create an event for sunday 2014/03/02 at 8 pm
• synchronize on another Desktop. Everything is ok (8 pm)
• synchronize on your Android Smartphone with the free app “CalDAV Sync Adapter”. Everything is ok (8 pm)
• synchronize on another Smartphone with DAVdroid. Then you see the event at 7 pm

This is always reproducible and only occurs on events at sundays.

Seems to be a very evil iCal4j bug. Could reproduce it for 2014/03/02 (Europe/Vienna); next and previous day or UTC time zone works.

Ok. So do you open an issue in the ical4j project or do you have a workaround?

I’m on it… it’s a very difficult issue. And I just tested it and now it works… created an event in Thunderbird on 2014/03/02 at 8 pm, synced, and there it is… I don’t have an idea what this can be

Can’t reproduce the bug anymore. The iCal4j tests that I made which failed yesterday (only on the Android device, not on my PC with plain Java!) work today… → WTF

Same here! I can’t reproduce it Every new event I create seems to work now.
I agree: WTF?!?
Close for now? And when it happens again we reopen the issue?

WTF²: I set the local date (not the date of the event, but the clock on the device!) on the Android device to yesterday (28 Feb) → bug is reproducible and occurs when syncing the event. Then I reset the local date to today (1 Mar) → bug is gone when syncing the same event (!). Date 31 Mar also has the bug.

Happens also for events in Europe/London, but NOT for UTC. So I guess this is a time zone/daylight saving time bug… which device/firmware do you have?

I’ve never seen such a strange behaviour

Newest findings:

TimeZone tz = DefaultTimeZoneRegistryFactory.getInstance().createRegistry().getTimeZone("Europe/London");
//Log.i(TAG, tz.getVTimeZone().toString());
		
DateTime date = new DateTime("20140302T080000Z");
date.setTimeZone(tz);
		
Log.i(TAG, date.toString());

returns different values, depending on local (Android) system time, see above…

Any news?

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");

works;

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 java.util.TimeZone(Europe/Vienna) and 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.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.

Thank you very much

Patch for iCal4j is available here: https://github.com/ical4j/ical4j/pull/14

Hi!

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.)

Greets

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?

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:

https://oss.sonatype.org/content/repositories/snapshots/org/mnode/ical4j/ical4j/master-SNAPSHOT/

@benfortuna Thanks for the info. When using the latest master snapshot, I get a ClassCastException: XComponent cannot be cast to VEVent when 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.

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.