http://bugzilla.moblin.org/show_bug.cgi?id=3009
--- Comment #31 from pohly <[email protected]> 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. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
