Recurring events do not appear to extend beyond November 2008

[dekkerdreyer@…]

Lightning, connected to Darwin Calendar Server, doesn't show repeating events past November 2008. The same event, saved on a WebDav, works fine.

I suspected this was a problem with Lightning/Sunbird, but it now appears to be a Calendar Server bug. There are some details related to what queries show repeating events and what queries do not. Please check this bug entry in bugzilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=407588

[agx@…]

Peter Mogensen noticed that DCS (1.2) will not return an event instance more than 356 days from the creation of the event in a calendar-query.

He found that these events are not put into the TIMESPAN index, which means that they are not returned by a search using the index.

Searches seems to not use the index when there's a time-range element in the filter, but the exception detecting this is only thrown from the filter expression generator for prop-filters, ... which again means that if you don't have a prop-filter in your query, you'll get a search using the index, which will ignore these 356+ days events.

[wsanchez@…]

The index is supposed to indicate how far out expansion has happened for each event, and if a query against the index goes beyond that time, the expansion should be brought out farther, up to a defined limit.

If we have expanded to the limit, then any queries that goes beyond the limit would have to read the icalendar data to see if that event matches (far more expensive, but the idea is that such queries should be rare).

The code is apparently not working as I described.

[apm@…]

Replying to wsanchez@apple.com:

The index is supposed to indicate how far out expansion has happened for each event, and if a query against the index goes beyond that time, the expansion should be brought out farther, up to a defined limit.

Yes but that indication is stored in the RESOURCE table in RECURRANCE_MAX and unless I'm sorely mistaken a simple grep will show that RECURRANCE_MAX is used no where in the 1.2 code except in "create table" statements and in the "insert into" statement which first inserts the event into the RESOURCE table. (index.py). No where is the value brought out farther.

I'm sad to see this bumped to milestone 2.x. I would suspect this to be a serious blocker for any practical use. No events of the "same time, next year" kind can be used in the calendar. Anniversaries and every other event more than 356 days into the future will also disappear.

[wsanchez@…]

Right, the bug is that we handling RECURRANCE_MAX correctly.

Sorry the milestone isn't satisfactory for you, but the reason its not at an earlier milestone is that desktop clients like iCal tend to do this sort of query based on their own local cache of everything in your calendar and not via CalDAV. Web clients which don't cache data are going to have to hit the server, but at the moment the number of CalDAV clients I'm aware of is rather low, and are all desktop clients.

iCal also happens to be a bit of a priority for us at Apple, and we don't have a lot of incoming patches from outside of the Apple team in this area yet. If you want to pitch in or someone else manages to send us some fixed, I'd be happy to pull the milestone in.

[apm@…]

Suggestion for solution posted to -dev list. Please comment.

[wsanchez@…]

r2825

[wsanchez@…]

Whoops, wrong ticket

[apm@…]

Proposal for patch against CalendarServer 1.2 sources

[apm@…]

fixed iCalendar export bug

[wsanchez@…]

At a glance, this looks OK, though we will need some unit tests.

Coding guidelines are here: source:CalendarServer/trunk/HACKING.