:-)
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
[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
