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). Because of that problem,
the CONVERTTOZONE() macro uses the incorrect GMT offset of 0 and the
EXDATE still doesn't match.

Bye, Patrick

On Fri, 2009-07-03 at 09:07 -0700, Patrick Ohly wrote:
> Hello!
> 
> Yanshuang found that Evolution and ScheduleWorld do not quite agree on
> the interpretation of EXDATE:
> http://bugzilla.moblin.org/show_bug.cgi?id=1805#c4
> 
> The server sends a recurring meeting relative to TZID=Europe/Berlin with
> EXDATE in UTC time:
> 
> DTSTART;TZID=/softwarestudio.org/Tzfile/Europe/Berlin:20090630T190000
> RRULE:FREQ=DAILY;UNTIL=20090702T170000Z;INTERVAL=1
> EXDATE:20090630T170000Z
> 
> Evolution (or, more likely, libical) does not recognize that the first
> instance of the event was cancelled and continues to show it.
> 
> Evolution itself creates an EXDATE relative to the time zone:
> EXDATE:20090630T190000
> 
> Lukas, Mark, do you have any thoughts on this?
> 
> Yongsheng might have found a similar issue with the Funambol server:
> http://bugzilla.moblin.org/show_bug.cgi?id=2422#c34
> 


_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to