9:37 p.m.
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
3:10 p.m.
New subject: [SyncEvolution] [os-libsynthesis] EXDATE in iCalendar 2.0
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.
4:04 p.m.
New subject: [SyncEvolution] [os-libsynthesis] EXDATE in iCalendar 2.0
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
os-libsynthesis(a)synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Lukas Zeller (luz(a)synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
info(a)synthesis.ch, http://www.synthesis.ch
4:28 p.m.
New subject: [SyncEvolution] [os-libsynthesis] EXDATE in iCalendar 2.0
On Wed, 2009-07-29 at 16:04 +0100, Lukas Zeller wrote:
it does look right to me, except I guess there's a typo in the
first
if (UT??Z??).
Right, good catch.
Thinking of it, why do you need to check for UTC at all? You can
simply convert all EXDATEs into the zone of DTSTART.
I wasn't sure how CONVERTTOZONE() would work for UTC. Also, the problem
only occurs for events in a timezone, so I wanted to minimize the impact
of the script to those events.
Perhaps the same transformation is really also useful for recurring
events in UTC with EXDATEs in a timezone. Hmm...
--
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.
4:13 p.m.
New subject: [SyncEvolution] [os-libsynthesis] EXDATE in iCalendar 2.0
On Wed, 2009-07-29 at 15:10 +0100, Patrick Ohly wrote:
On Tue, 2009-07-28 at 21:37 +0100, Patrick Ohly wrote:
[old
revision of EXDATE conversion]
> Does that look right?
Hah, no-one dared to say anything! You missed your chance to spot a
weakness in the code above, caught by the SyncEvolution
ical20::testItems test: EXDATEs for all-day events are dates, not times,
so converting them does not make sense.
Here's the updated code. I'm still interested in comments, although I'll
go ahead and give it a try in the nightly testing:
// 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;
timestamp exdate;
while (i<SIZE(EXDATES)) {
exdate = EXDATES[i];
if (!ISDATEONLY(exdate) &&
(TIMEZONE(exdate) == "UTC" || ISFLOATING(exdate))) {
// "unfloat" floating time stamps: not sure whether that occcurs
// in practice, but it looks as wrong as UTC EXDATEs
EXDATES[i] = CONVERTTOZONE(exdate,DTSTART,TRUE);
}
i=i+1;
}
}
--
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.
4:32 p.m.
New subject: [SyncEvolution] [os-libsynthesis] EXDATE in iCalendar 2.0
:-)
I dared to say ok just a few minutes ago - but missed the DATE-only
case, indeed...
As said, I don't see why you check for UTC - why not simply:
// 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 (!ISFLOATING(DTSTART)) {
i = 0;
timestamp exdate;
while (i<SIZE(EXDATES)) {
exdate = EXDATES[i];
if (!ISDATEONLY(exdate)) {
// "unfloat" floating time stamps: not sure whether that
occcurs
// in practice, but it looks as wrong as UTC EXDATEs
EXDATES[i] = CONVERTTOZONE(exdate,DTSTART,TRUE);
}
i=i+1;
}
}
I'm not even sure the test for non-floating is required - without
actually checking I'd say CONVERTTOZONE() would simply make the
EXDATEs floating if DTSTART is floating.
Best Regards,
Lukas
PS: The reason why the sample config does not have (nor need, I'd say)
such a normalisation is because when data is stored in tabular form,
i.e. mapped field-by-field, the mapping mechanism takes care of
normalizing timestamps to "database time zone" (can be configured
otherwise, but serveral calendar DBs I've seen so far store UTC -
although, remembering a past discussion, this can cause
misrepresentations when time zone definitions change after an event).
On Jul 29, 2009, at 17:13 , Patrick Ohly wrote:
On Wed, 2009-07-29 at 15:10 +0100, Patrick Ohly wrote:
> On Tue, 2009-07-28 at 21:37 +0100, Patrick Ohly wrote:
[old revision of EXDATE conversion]
>> Does that look right?
Hah, no-one dared to say anything! You missed your chance to spot a
weakness in the code above, caught by the SyncEvolution
ical20::testItems test: EXDATEs for all-day events are dates, not
times,
so converting them does not make sense.
Here's the updated code. I'm still interested in comments, although
I'll
go ahead and give it a try in the nightly testing:
// 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;
timestamp exdate;
while (i<SIZE(EXDATES)) {
exdate = EXDATES[i];
if (!ISDATEONLY(exdate) &&
(TIMEZONE(exdate) == "UTC" || ISFLOATING(exdate))) {
// "unfloat" floating time stamps: not sure whether
that occcurs
// in practice, but it looks as wrong as UTC EXDATEs
EXDATES[i] = CONVERTTOZONE(exdate,DTSTART,TRUE);
}
i=i+1;
}
}
--
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
os-libsynthesis(a)synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Lukas Zeller (luz(a)synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
info(a)synthesis.ch, http://www.synthesis.ch
4674
days inactive
4675
days old
syncevolution@synevolution.org
5 comments
2 participants
participants (2)
-
Lukas Zeller -
Patrick Ohly