STR: * Create a recurring event * Create an exception (i.e move an occurrence to a different time) * Synchronize * In Google Calendar, open the exception, put the exception back into the series * Synchronize Results: * The occurrence is still treated as an exception * The XML received is identical to the one received when an exception is created Expected: * The exception item could be compared to the master event to see if everything is the same. * The exception should be removed from the master item This could also be solved by making calIRecurrenceInfo::modifyException() check if all properties are the same and automatically remove the exception in such cases.

Isn't this a general enhancement since ICS et al write the same?

Not quite, the outcome is that Google knows nothing about the exception (i.e if you get the uncached feed, Google will not note that occurrence as an exception, since you un-excepted it via the web interface), but sb/ltn still thinks it is an exception, and saves it as such in the storage calendar. Example: * create event with 3 occurrences * Make all three occurrences exceptions by moving each to a different time * Go to the web interface, undo the changes to move the exceptions back into the series. * Sync * Sunbird thinks that it is still an event with three exceptions, but each at the original event time. calling .getExceptionIds({}) will give you three ids (incorrect) * If you retrieve the uncached item feed, google will report no exceptions at all and present you with the recurring master item. (correct)

This doesn't sound exactly the same as 448979, but perhaps underneath they are the same root cause. When is a fix coming?

I'll need to prepare a Google Groups posting for the Calendar Data API Group and/or file a bug on the issue tracker. Then it usually takes quite some time (1/2 Yr+?) for Google to fix the bug in the API. Things might get better if CalDAV evolves faster.

Interesting... perhaps I'm in a different line of business with software/hardware development, but that slow of response puts us out of business. The ability to update/modify a single instance of a reoccurring event is a basic function of calendaring. Perhaps they don't care since it works online, and is only broken via 3rd party apps.

mobilegcal used to not allow modifying reoccurring events, but now allows it. That seems to imply it was the 3rd party software, not google calendar. Are you 100% sure Thunderbird Lightning caching isn't at fault?

Do they download the files with the updated-min parameter (use wireshark or similar to find out)? If not, then they can obviously allow editing those events. If they use this parameter, which is afaik the only one that allows an incremental sync, then they should be having the same problems.

There has been a major rewrite of the Provider for Google Calendar between version 0.32 and 1.0. A vast number of bugs have been fixed during this rewrite, therefore I am closing lots of old bugs that I think might either be fixed or no longer apply to the latest version. Please read the updated FAQ [1] for details on known issues. If you can reproduce your issue with the latest version of the Provider for Google Calendar and you can't find an existing bug that handles your case, please reopen this issue. Thank you for your understanding. [1] https://wiki.mozilla.org/Calendar:GDATA_Provider