Hi Patrick,
it does look right to me, except I guess there's a typo in the first
if (UT??Z??).
Thinking of it, why do you need to check for UTC at all? You can
simply convert all EXDATEs into the zone of DTSTART.
Best Regards,
Lukas Zeller
On Jul 29, 2009, at 16:10 , Patrick Ohly wrote:
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
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
