On Fri, 2011-11-04 at 20:24 +0100, Ove Kåven wrote: > Den 01. nov. 2011 13:43, skrev Patrick Ohly: > > On Tue, 2011-11-01 at 07:35 +0100, Ove Kåven wrote: > >> It did not seem to quite work for me. The backend now stores EXDATEs > >> that look like > >> > >> EXDATE:19700101T000000Z > >> > >> I suppose I'll need to take a look at why that happens later on. > > > > Remember to set loglevel=4 in both sync and target config, to get full > > logging on both sides. > > There's some bug that causes it to bork if the EXDATE has a property > (like TZID). The calendar-backend doesn't check the property anyway; it > can go to UTC if the time itself has a "Z" suffix, but no other timezone > overrides seem possible for this field. > > Would you know of another of those magic rules that would remove that > TZID property?
Sorry, I didn't follow. So you have a RECURRENCE-ID with TZID which gets converted into an EXDATE with that TZID? And you want to have an EXDATE instead with that TZID+value converted into UTC? That can be done with a before-write script for the Maemo calendar backend. Grep for VCARD_BEFOREWRITE_SCRIPT_EVOLUTION to see how such a script is defined and enabled. The content of that script has to be a loop over the new recurrence IDs array field. I can provide another patch if that is what you need. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
