4:19 a.m.
http://bugzilla.moblin.org/show_bug.cgi?id=3009
--- Comment #31 from pohly <patrick.ohly(a)intel.com> 2009-07-30 04:19:52 ---
(In reply to comment #30)
(In reply to comment #28)
> (In reply to comment #27)
> > 4 'EXDATE': It has the same interpretation as scheduleworld but
different
> > from evolution for a specified time.
>
> Bug #4457, right?
>
> Given that we now have two servers with this behavior and ScheduleWorld is slow
> with changing their server, perhaps we should really implement a workaround for
> this in the Synthesis incoming script.
Patrick, I found you have fixed bug $4457.
Could it solve below 2 issues?
1.
client server
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
SUMMARY:all day event SUMMARY:all day event
DESCRIPTION:all day event DESCRIPTION:all day event
DTEND;VALUE=DATE:20060407 | DTEND:20060406T225959Z
DTSTART;VALUE=DATE:20060406 | DTSTART:20060405T230000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
This is the problem that Dries mentioned at the beginning of this issue
(comment #7).
The reason why 'DTSTART' and 'DTEND' has the time of
'23:00' in the server's
side is because the account's timezone is GMT +1:00
I think right fix is for the server a) to represent all-day events in iCalendar
2.0 as VALUE=DATE (avoids any kind of guessing on the client side) or if that
isn't possible, b) use floating time instead of UTC.
I haven't thought much about it, but perhaps we can relax the all-day detection
in the incoming script so that it detects UTC, adds the device's current GMT
offset, and only then compares against 00:00-23:59.
2.
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
SUMMARY:recurrence\, daily\, with e SUMMARY:recurrence\, daily\, with e
xceptions xceptions
DESCRIPTION:recurrs seven times\, e DESCRIPTION:recurrs seven times\, e
xcluding (but counting) Friday and xcluding (but counting) Friday and
Saturday Saturday
DTEND:20060406T190000Z DTEND:20060406T190000Z
DTSTART:20060406T183000Z DTSTART:20060406T183000Z
EXDATE:20060407 | EXDATE:20060407T000000Z
EXDATE:20060408 | EXDATE:20060408T000000Z
RRULE:FREQ=DAILY;UNTIL=20060412T183 RRULE:FREQ=DAILY;UNTIL=20060412T183
000Z 000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
No, this won't be fixed by my patch for the incoming script. First, it is not
applied to UTC events, like this one. Lukas argued that this additional check
is unnecessary, so we could change this. Second, more important, it does not
convert back from date+time (20060407T000000Z) to date (20060407).
It's interesting that Evolution at some point must have created EXDATE with
VALUE=DATE. I think the current version creates DATE-TIME and expects the time
to match, if one is given (#4457).
Can you check whether the time is really relevant for daily, weekly, yearly
recurrence? In other words, does Evolution properly skip occurrences in EXDATE
VALUE=DATE?
Then we might work around the issue above by stripping the time from EXDATEs.
For hourly recurrence it must be preserved and we need to convert to the
DTSTART timezone, as currently done as part of #4457.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.