Outcome: The exception is not visible in the Owncloud web client, the event is still there. The event is still listed in Lightning with a strike-through effect:
Expected result: The event should not be visible on the date the exception was made for, neither in Owncloud nor Lightning.
This is a behaviour of your calendar app. It doesn’t set an EXDATE (meaning that on this day, there’s no recurrence) but overrides the specific occurence of this day by “STATUS:CANCELLED” which is then shown as strike-through in Lightning.
DAVdroid has no influence on this, see also: https://twitter.com/davdroidapp/status/527057795980754945
Procedure: Create and sync an event exception using Lightning.
Outcome: The exception is reflected in the Owncloud web client (the event is gone on that date). On Android+DAVdroid, the event is still present on the date the exception was made for and does not show any kind of alteration.
Expected result: The event should not be visible on the date the exception was made for, neither in Owncloud (matches the Outcome above), nor Android (where DAVdroid seems to fail integrating the exception properly).
It seems that EXDATEs with UTC time zone (yyyymmddThhmmssZ) were inserted as local time into the calendar store, which expects either an explizit time zone or UTC with …Z. This has been fixed now.
Thank your for your great and quick support!
I think I found a hack to force eGroupware to always use DATE-TIME with correct value format.
At least it did work for me synchronizing calendar, address book and tasks (infolog in eGroupware) .
When it proofs to be stable, I will send it to the eGroupware community site - maybe they are interested …
Btw. we are not so far apart, I live in Mödling
Bye, Peter 2.0