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?
-
Wrong start time
-
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) andnet.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 callTimeZone.getOffset(long)
when a timezone is passed, while Android’s Java seems to callTimeZone.getOffset(era,y,m,d,dow,ms)
. Only the latter one has bugs in thenet.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 ofDAY_OF_MONTH
, soDAY_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.
-
This bug is so annoying that I have to uninstall Davdroid and search for another app
-
@rfc2822 the 1.0.x snapshot builds are also available on sonatype here:
https://oss.sonatype.org/content/repositories/snapshots/org/mnode/ical4j/ical4j/1.0.6-SNAPSHOT/
Do you have a sample input file to reproduce the ClassCastException on master?
-
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.
Thanks. -
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?