If you are still interested in using DAVdroid with Memotoo, please contact Memotoo directly because it’s an issue on their side.
"TimeZone is not applicable to current value" sync error
-
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! -
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 aRECURRENCE-ID
with date/time (AndroidORIGINAL_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 ofORIGINAL_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 fromORIGINAL_ALL_DAY
) is not the same as the type ofDTSTART
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.
-
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
-
@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.
-
@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?
-
@yannik Oh… I’m sorry, I should have mentioned that. What has not been synchronized to the server is probably lost.
-
I’ve emailed BC2 support today to get an update on the issue, since I didn’t hear back from them.