Hello again! There was no problem of ICSdroid. I pasted an URL that I’ve send to myself. and that was converted to ASCII, so that I pasted amp;instead of &. Now its working fine.
java.lang.NoClassDefFoundError: org.threeten.bp.zone.ZoneRulesProvider
-
Hi,
I have a working davdroid setup since a while, but recently I get errors for two cal events like this one:
EXCEPTION: java.lang.NoClassDefFoundError: org.threeten.bp.zone.ZoneRulesProvider at org.threeten.bp.zone.ZoneRulesProvider.getRules(ZoneRulesProvider.java:132) at org.threeten.bp.ZoneRegion.ofId(ZoneRegion.java:143) at org.threeten.bp.ZoneId.of(ZoneId.java:357) at org.threeten.bp.ZoneId.of(ZoneId.java:285) ...
I attached the full debug log: 0_1503307841503_debug.txt
How can I add more debug information ? I don’t have access to the nextcloud server.
-
Where did you get this DAVdroid version from? Sounds like ical4j can’t generate the TimeZone from the system time zones because of a missing provider class.
What’s the content of https://cloud.myprovider.org/remote.php/dav/calendars/varac/personal/223816a8-0180-41e8-b446-e2720ca287fe.ics (anonymized, but time zone info is important)?
Are there known problems with your system’s time zones?
-
Where did you get this DAVdroid version from? Sounds like ical4j can’t generate the TimeZone from the system time zones because of a missing provider class.
Latest davdroid from f-droid is installed (1.6.5-ose).
Here’s the content of 223816a8-0180-41e8-b446-e2720ca287fe.ics:0_1503313997536_223816a8-0180-41e8-b446-e2720ca287fe.ics
Looks like a task created with todoman.
And no, I don’t have any problems with my timezone setup so far (all other events/tasks work fine).
-
Very strange. I don’t have any idea what the reason of this could be. Does the same calendar work on other devices?
-
Yes, I just migrated from my old device (some cyanogenmod version) to a new one (latest lineage os), hoping it will go away but it didn’t.
-
@varac Can you provide a test account where this problem happens so that I can try to reproduce it?
-
I can ask the provider to create a test account, yes.
But At least now I know how to download and analyse the failing .ics, and can also just remove it from the server. I’d be fine with that.
Just tell me what’s better for you.
-
@varac Just delete it. I’ll upload this task to our testing server and see whether it causes problems there.
-
Here’s the second failing task:
-
Both have
TZID=CET
and I suspect this to be related to the problem. Are your other events/tasks in CET, too? -
A quick and dirty search shows all sed timezones (oh boy respect for dealing with all these crazy notations):
--- calendars/personal » grep TZID -ir | cut -d':' -f 2- | sed 's/DT.*;//' | sed 's/:20.*$//' | sort | uniq COMPLETED;TZID=CEST;VALUE=DATE-TIME DUE;TZID=CEST;VALUE=DATE-TIME DUE;TZID=CET;VALUE=DATE-TIME DUE;TZID=Europe/Berlin TZID=America/Sao_Paulo TZID=Europe/Amsterdam TZID:Europe/Amsterdam TZID=Europe/Berlin TZID:Europe/Berlin TZID:Europe/Berlin TZID=/freeassociation.sourceforge.net/Europe/Amsterdam TZID=/freeassociation.sourceforge.net/Europe/Amsterdam: TZID:/freeassociation.sourceforge.net/Europe/Amsterdam TZID=/freeassociation.sourceforge.net/Europe/Berlin: TZID:/freeassociation.sourceforge.net/Europe/Berlin TZID=/freeassociation.sourceforge.net/Europe/Brussels
Timezone CET is rarely used, only 6 events/tasks have it.
-
I’m new to this forum, don’t know how to private message you, but I can pass you an invite code to create a test account on my provider if you ping me.
-
I can confirm that it’s indeed todoman which uses for new tasks i.e.
TZID=CET;
in my case, even though I have:
» cat /etc/timezone Europe/Berlin
-
- Seems that todoman uses TZID without specifying its VTIMEZONE, which is not allowed in CalDAV (there MUST be a VTIMEZONE for each TZID). Can you please report that to todoman and maybe provide a reference link here?
- DAVdroid should fall back to UTC for unknown time zones. Also, this exception should not occur even when the timezone is completely unknown. I’ll try to reproduce the problem here and see why it’s happening.
-
@rfc2822 Thx, I will do this !
-
I created the todoman issue.
-
@rfc2822 Regarding the CET timezone, do you consider it a regular timezone that davdroid should handle ?
-
@varac said in java.lang.NoClassDefFoundError: org.threeten.bp.zone.ZoneRulesProvider:
@rfc2822 Regarding the CET timezone, do you consider it a regular timezone that davdroid should handle ?
This is what the VTIMEZONE is needed for. With the VTIMEZONE, every time zone can be handled correctly.
-
I could reproduce the problem for release builds (not for debug builds). Maybe some ProGuard problem …
-
The DAVdroid part should be fixed with 968df1ce:
# proguard-rules.txt keep class org.threeten.bp.** { *; } # keep ThreeTen (for time zone processing)
The missing time zone has to be fixed in todoman.