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
>> 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
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.