On Tue, 2009-07-28 at 21:37 +0100, Patrick Ohly wrote:
> Hello!
>
> I've started to look at a workaround for this inside the Synthesis XML
> configuration. My expectation is that if DTSTART is relative to a
> timezone, then EXDATEs should also be relative to that same timezone.
> UTC or floating do not make sense, because if the timezone definition
> changes, those exceptions might no longer match.
>
> Following that logic I came up with this snipped for the incoming
> calendar event script:
>
> // Make sure that all EXDATE times are in the same timezone as the
> start
> // time. Some servers send them as UTC, which is all fine and well,
> but
> // only if the timezone definition doesn't change. Also, libical does
> not
> // handle such UTC EXDATEs, so let's convert it while the UTC and
> // time zone definition (hopefully) are in sync.
> if (TIMEZONE(DTSTART) != "UTZ" && !ISFLOATING(DTSTART)) {
> i = 0;
> while (i<SIZE(EXDATES)) {
> if (TIMEZONE(EXDATES[i]) == "UTC" || ISFLOATING(EXDATES[i])) {
> // "unfloat" floating time stamps: not sure whether that occcurs
> // in practice, but it looks as wrong as UTC EXDATEs
> EXDATES[i] = CONVERTTOZONE(EXDATES[i],DTSTART,TRUE);
> }
> i=i+1;
> }
> }
>
> Does that look right?
>
> I think it would work if it wasn't for the libical VTIMEZONE parsing
> problem on my test machine (see other email).
It does indeed work after making sure that the relevant Europe/Berlin
VTIMEZONE was parsed correctly. I tried "refresh-from-server" with a
ScheduleWorld server which had a repeating event with exception: without
this change, Evolution ignored the exception. With the change, Evolution
shows the same days as ScheduleWorld.
Can someone give me his thumbs-up about this change? Initially it would
go into the SyncEvolution XML config, but it might also be useful for
the Synthesis syncclient_sample_config.xml.
--
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.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
