java.lang.NoClassDefFoundError: org.threeten.bp.zone.ZoneRulesProvider

[varac]

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.

[rfc2822]

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?

[varac]

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

[rfc2822]

Very strange. I don’t have any idea what the reason of this could be. Does the same calendar work on other devices?

[varac]

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.

[rfc2822]

@varac Can you provide a test account where this problem happens so that I can try to reproduce it?

[varac]

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.

[rfc2822]

@varac Just delete it. I’ll upload this task to our testing server and see whether it causes problems there.

[varac]

Here’s the second failing task:

0_1503315527171_debug.txt

0_1503315496409_9ecd5e92-6c0a-4b26-8e1a-f971c7bb1869.ics

[rfc2822]

Both have TZID=CET and I suspect this to be related to the problem. Are your other events/tasks in CET, too?

[varac]

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.

[varac]

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.

[varac]

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

[rfc2822]

1. 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?
2. 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.

[varac]

@rfc2822 Thx, I will do this !

[varac]

I created the todoman issue.

[varac]

@rfc2822 Regarding the CET timezone, do you consider it a regular timezone that davdroid should handle ?

[rfc2822]

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

[rfc2822]

I could reproduce the problem for release builds (not for debug builds). Maybe some ProGuard problem …

[rfc2822]

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.