On Sat, 2011-11-05 at 09:24 +0100, Ove Kåven wrote:
> Den 04. nov. 2011 20:37, skrev Patrick Ohly:
> > 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:
> > And you want to have an EXDATE
> > instead with that TZID+value converted into UTC?
>
> I don't need UTC, just that the TZID goes away. Without TZID, it'll use
> the event's timezone (same as DTSTART, I think). Since normally, the
> exceptions have the same timezone as the event itself, it's probably not
> necessary to do much conversion.
I don't understand why an explicit TZID which specifies the event's time
zone is bad when that's the time zone that is going to be used anyway,
but so be it ;-) A bug?
Anyway, getting rid of the TZID is easy. It is generated by the TZID
parameter in the modified calendar profile:
<!-- encode as normal EXDATE when backend asks for it -->
<property name="EXDATE" show="no" rule="HAVE-EXDATE-DETACHED"
mandatory="no">
<value field="EXDATES_DETACHED"/>
===> <parameter name="TZID" default="no" show="yes">
<value field="EXDATES_DETACHED" conversion="TZID"/>
</parameter>
<position field="EXDATES_DETACHED" repeat="array" increment="1"
minshow="0"/>
</property>
You can comment out the whole <parameter></parameter> part or remove it
to try out whether it works.
The final solution will be to have two kinds of "include
EXDATES_DETACHED field as EXDATE" entries: one with TZID, one without.
Like this:
<!-- encode as normal EXDATE when backend asks for it -->
<property name="EXDATE" show="no" rule="HAVE-EXDATE-DETACHED"
mandatory="no">
<value field="EXDATES_DETACHED"/>
<parameter name="TZID" default="no" show="yes">
<value field="EXDATES_DETACHED" conversion="TZID"/>
</parameter>
<position field="EXDATES_DETACHED" repeat="array" increment="1"
minshow="0"/>
</property>
<!-- encode as EXDATE without TZID when backend asks for it -->
<property name="EXDATE" show="no" rule="HAVE-EXDATE-DETACHED-NO-TZID"
mandatory="no">
<value field="EXDATES_DETACHED"/>
<position field="EXDATES_DETACHED" repeat="array" increment="1"
minshow="0"/>
</property>
Then in the Maemo backend patch, enable HAVE-EXDATE-DETACHED-NO-TZID
instead of HAVE-EXDATE-DETACHED.
> > 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.
>
> Where is that language defined?
Both the Synthesis configuration XML quoted above and the procedural
scripting language embedded in it are defined in the
libsynthesis/doc/SySync_config_reference.pdf
--
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
