"TimeZone is not applicable to current value" sync error

yannik

Hello,
upon sync, a “TimeZone is not applicable to current value” error notification appears. (Calendar entries are not synced)

Here is the full log: https://pastebin.com/jhJ08FDf

This is the stacktrace:

EXCEPTION:
java.lang.UnsupportedOperationException: TimeZone is not applicable to current value
    at net.fortuna.ical4j.model.property.DateProperty.updateTimeZone(DateProperty.java:184)
    at net.fortuna.ical4j.model.property.DateProperty.setTimeZone(DateProperty.java:154)
    at at.bitfire.ical4android.Event.write(Event.kt:215)
    at at.bitfire.davdroid.syncadapter.CalendarSyncManager$prepareUpload$1.invoke(CalendarSyncManager.kt:89)
    at at.bitfire.davdroid.syncadapter.CalendarSyncManager$prepareUpload$1.invoke(CalendarSyncManager.kt:42)
    at at.bitfire.davdroid.syncadapter.SyncManager.useLocal(SyncManager.kt:798)
    at at.bitfire.davdroid.syncadapter.CalendarSyncManager.prepareUpload(CalendarSyncManager.kt:84)
    at at.bitfire.davdroid.syncadapter.CalendarSyncManager.prepareUpload(CalendarSyncManager.kt:42)
    at at.bitfire.davdroid.syncadapter.SyncManager$uploadDirty$2$1.invoke(SyncManager.kt:318)
    at at.bitfire.davdroid.syncadapter.SyncManager$uploadDirty$2$1.invoke(SyncManager.kt:54)
    at at.bitfire.davdroid.syncadapter.SyncManager.useRemote(SyncManager.kt:812)
    at at.bitfire.davdroid.syncadapter.SyncManager$uploadDirty$2.invoke(SyncManager.kt:316)
    at at.bitfire.davdroid.syncadapter.SyncManager$uploadDirty$2.invoke(SyncManager.kt:54)
    at at.bitfire.davdroid.syncadapter.SyncManager.useLocal(SyncManager.kt:798)
    at at.bitfire.davdroid.syncadapter.SyncManager.uploadDirty(SyncManager.kt:312)
    at at.bitfire.davdroid.syncadapter.SyncManager$performSync$1.invoke(SyncManager.kt:127)
    at at.bitfire.davdroid.syncadapter.SyncManager$performSync$1.invoke(SyncManager.kt:54)
    at at.bitfire.davdroid.syncadapter.SyncManager.unwrapExceptions(SyncManager.kt:838)
    at at.bitfire.davdroid.syncadapter.SyncManager.performSync(SyncManager.kt:113)

Here is the local resource that causes this:

LOCAL RESOURCE:
LocalEvent=[eTag=79130726-101325218, fileName=681479e6-1fb7-4cf2-8e27-542f865f1a4d.ics, flags=1, weAreOrganizer=true, calendar=at.bitfire.davdroid.resource.LocalCalendar@bcc0644, event=Event=[alarms=[BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:K-Dienst
END:VALARM
], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=null, dtStart=DTSTART;TZID=Europe/Berlin:20190110T083000, duration=DURATION:PT18000S, exDates=[], exRule=null, exceptions=[Event=[alarms=[BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:K-Dienst
END:VALARM
], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=DTEND;TZID=Europe/Berlin:20190124T131500, dtStart=DTSTART;TZID=Europe/Berlin:20190124T081500, duration=null, exDates=[], exRule=null, exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRule=null, recurrenceId=RECURRENCE-ID;TZID=Europe/Berlin:20190124T083000, status=STATUS:CONFIRMED, summary=K-Dienst, unknownProperties=[], sequence=1, uid=681479e6-1fb7-4cf2-8e27-542f865f1a4d], Event=[alarms=[BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:K-Dienst
END:VALARM
], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=DTEND;TZID=Europe/Berlin:20190131T131500, dtStart=DTSTART;TZID=Europe/Berlin:20190131T081500, duration=null, exDates=[], exRule=null, exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRule=null, recurrenceId=RECURRENCE-ID;TZID=Europe/Berlin:20190131T083000, status=STATUS:CONFIRMED, summary=K-Dienst, unknownProperties=[], sequence=1, uid=681479e6-1fb7-4cf2-8e27-542f865f1a4d], Event=[alarms=[BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:-½ K-Dienst
END:VALARM
], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=DTEND;TZID=Europe/Berlin:20190110T130000, dtStart=DTSTART;TZID=Europe/Berlin:20190110T083000, duration=null, exDates=[], exRule=null, exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRule=null, recurrenceId=RECURRENCE-ID;TZID=Europe/Berlin:20190110T083000, status=STATUS:CONFIRMED, summary=-½ K-Dienst, unknownProperties=[], sequence=1, uid=681479e6-1fb7-4cf2-8e27-542f865f1a4d], Event=[alarms=[BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:- ½ K-Dienst
END:VALARM
], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=DTEND;TZID=Europe/Berlin:20190117T133000, dtStart=DTSTART;TZID=Europe/Berlin:20190117T083000, duration=null, exDates=[], exRule=null, exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRule=null, recurrenceId=RECURRENCE-ID;TZID=Europe/Berlin:20190117T083000, status=STATUS:CONFIRMED, summary=- ½ K-Dienst, unknownProperties=[], sequence=1, uid=681479e6-1fb7-4cf2-8e27-542f865f1a4d], Event=[alarms=[BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:K-Dienst Kobolde! bis 12:30!
END:VALARM
], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=DTEND;TZID=Europe/Berlin:20190207T123000, dtStart=DTSTART;TZID=Europe/Berlin:20190207T083000, duration=null, exDates=[], exRule=null, exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRule=null, recurrenceId=RECURRENCE-ID;TZID=Europe/Berlin:20190207T083000, status=STATUS:CONFIRMED, summary=K-Dienst Kobolde! bis 12:30!, unknownProperties=[], sequence=1, uid=681479e6-1fb7-4cf2-8e27-542f865f1a4d], Event=[alarms=[BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:K-Dienst Kobolde!
END:VALARM
], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=DTEND;TZID=Europe/Berlin:20190214T133000, dtStart=DTSTART;TZID=Europe/Berlin:20190214T083000, duration=null, exDates=[], exRule=null, exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRule=null, recurrenceId=RECURRENCE-ID;TZID=Europe/Berlin:20190214T083000, status=STATUS:CONFIRMED, summary=K-Dienst Kobolde!, unknownProperties=[], sequence=1, uid=681479e6-1fb7-4cf2-8e27-542f865f1a4d], Event=[alarms=[BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:Ü-frei
END:VALARM
], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=DTEND;VALUE=DATE:20190222, dtStart=DTSTART;VALUE=DATE:20190221, duration=null, exDates=[], exRule=null, exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRule=null, recurrenceId=RECURRENCE-ID;VALUE=DATE:20190221, status=STATUS:CONFIRMED, summary=Ü-frei, unknownProperties=[], sequence=1, uid=681479e6-1fb7-4cf2-8e27-542f865f1a4d], Event=[alarms=[BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:K-Dienst
END:VALARM
], attendees=[], categories=[], classification=null, color=null, description=null, dtEnd=DTEND;TZID=Europe/Berlin:20190228T133000, dtStart=DTSTART;TZID=Europe/Berlin:20190228T083000, duration=null, exDates=[], exRule=null, exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRule=null, recurrenceId=RECURRENCE-ID:20190228T073000Z, status=STATUS:CONFIRMED, summary=K-Dienst, unknownProperties=[], sequence=1, uid=null]], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRule=RRULE:FREQ=WEEKLY;WKST=MO;UNTIL=20190307T072959Z;BYDAY=TH, recurrenceId=null, status=STATUS:CONFIRMED, summary=K-Dienst, unknownProperties=[], sequence=1, uid=681479e6-1fb7-4cf2-8e27-542f865f1a4d], id=1491]

The calendar entries were created using business calendar 2.
Thanks in advance for looking at this!

rfc2822

Hello,

Thanks for the verbose description and the logs. The problem is caused by the representation of the event in your Android calendar storage. The event has a date/time start DTSTART;TZID=Europe/Berlin:20190110T083000 and a recurring rule. So, all exceptions should have a RECURRENCE-ID with date/time (Android ORIGINAL_ALL_DAY=0), too. This is the case for all exceptions but this one: RECURRENCE-ID;VALUE=DATE:20190221.

This is an error because 20190221 is not a valid instance of the original event. In the calendar storage, ORIGINAL_ALL_DAY is 1 instead of 0.

I could reproduce the problem with Business Calendar 2.37.2 (which I personally like very much, by the way) with these steps:

Create a recurring date/time event (e.g. 1.1.2020 10:00 Europe/Vienna, 10 times).
Sync the event (so that exceptions can be created).
Change one occurrence (e.g. the one on 2.1.2020) to a full-day event in Business Calendar.
Sync the event – the problem will occur.
Verify with adb shell content query --uri content://com.android.calendar/events: originalAllDay=1 instead of 0.

Other calendar apps like Google Calendar are not affected.

My conclusions:

When the user creates a full-day exception of a date/time event, Business Calendar currently sets the exception to ORIGINAL_ALL_DAY=1,ALL_DAY=1 instead of ORIGINAL_ALL_DAY=0,ALL_DAY=1. This is a problem of Business Calendar.
DAVx⁵ should be able to ignore such cases instead of stopping synchronization with an error message like it currently does. So DAVx⁵ will now drop exceptions whose RECURRENCE-ID value type (which is calculated from ORIGINAL_ALL_DAY) is not the same as the type of DTSTART because DAVx⁵ should be strict in what it sends and servers may reject such an event. In your case, this means that the (invalid) exception on 20190222 won’t be taken into consideration when the VEVENT is prepared for sending.

So:

Can you please contact Business Calendar about this problem and provide this posting as a reference?
The DAVx⁵ patch (= don’t abort with error message in this case anymore) will be contained in the next version. If you want, I can send an APK/publish a beta for testing.

yannik

Hi,
thanks for your prompt investigation and reply, it is greatly appreciated.

I’ve emailed appgenix (who’s behind Business Calendar) explaining the bug and linking this thread. I’ll report back once I get a reply.

I’d very much appreciate you sending me a beta-apk.

If I understand correctly, full-day exceptions to date-time recurring events will now simply be discarded during sync? Could the invalid data automatically be corrected?

P.S. I will send a small donation your way via wire transfer as per https://www.davx5.com/donate

rfc2822

@yannik said in "TimeZone is not applicable to current value" sync error:

I’ve emailed appgenix (who’s behind Business Calendar) explaining the bug and linking this thread. I’ll report back once I get a reply.

Very good, thanks.

I’d very much appreciate you sending me a beta-apk.

I’ve just seen that you have the F-Droid version. I can send you an APK, but you would have to completely uninstall F-Droid DAVx⁵ and then install the beta APK (because different signing keys are used). As an alternative, you could

delete this specific event from your calendar to continue synchronization
unselect the calendar in DAVx⁵, force sync, select the calendar again, force sync to continue synchronization.

If I understand correctly, full-day exceptions to date-time recurring events will now simply be discarded during sync?

Yes, because they should not appear.

Could the invalid data automatically be corrected?

Yes (I have also thought about that) and it would surely increase stability on the on side; but on the other side, repairing things is not within the scope of DAVx⁵ (although it’s really required or easy to do) and causes complexity (and thus bugs in not-well tested cases). Because the case shouldn’t appear anyway, I think we should wait for a respoonse of appgenix now.

yannik

@rfc2822 said in "TimeZone is not applicable to current value" sync error:

I’ve just seen that you have the F-Droid version. I can send you an APK, but you would have to completely uninstall F-Droid DAVx⁵ and then install the beta APK (because different signing keys are used). As an alternative, you could

delete this specific event from your calendar to continue synchronization

unselect the calendar in DAVx⁵, force sync, select the calendar again, force sync to continue synchronization.

According to your instructions I:

deleted the event in question
force-synced (this generated the error again)
unselected the calendar in davx5
force-synced
selected the calendar again
force-synced

However, all calendar entries created since the error occured for the first time seem to be gone! That would be quite a disaster. How can I remedy this?

rfc2822

@yannik Oh… I’m sorry, I should have mentioned that. What has not been synchronized to the server is probably lost.

"TimeZone is not applicable to current value" sync error

Similar topics

Widget to start manual sync
DAVx⁵ • • AutoImport-OvOwl

SSLProtocolException "No access possible to the CalDAV or CardDAV service"
DAVx⁵ • duplicate • • storkii

Carddav Error
DAVx⁵ • synology connectivity • • Stefan Mewißen

"TimeZone is not applicable to current value" sync error

Similar topics

Widget to start manual sync DAVx⁵ • • AutoImport-OvOwl

SSLProtocolException "No access possible to the CalDAV or CardDAV service" DAVx⁵ • duplicate • • storkii

Carddav Error DAVx⁵ • synology connectivity • • Stefan Mewißen

Widget to start manual sync
DAVx⁵ • • AutoImport-OvOwl

SSLProtocolException "No access possible to the CalDAV or CardDAV service"
DAVx⁵ • duplicate • • storkii

Carddav Error
DAVx⁵ • synology connectivity • • Stefan Mewißen