http://bugzilla.moblin.org/show_bug.cgi?id=3009
--- Comment #33 from pohly <[email protected]> 2009-08-04 05:41:30 --- (In reply to comment #32) > > 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. > Mobical.net only support vCalendar1.0. I don't know whether it affects your > first fix. Indeed, I think there is no VALUE=DATE in vCalendar. > For b), I think we can post it to ask Björn's comments. Yes, please do. > > 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. > I am not sure I understand your meaning. My concern is devics's GMT offset may > be not the same as server's setting so it may not be converted to 00:00-23:59. My assumption is that the user has configured his server account and his device to be in the same time zone. That's a best-known-method for example with Funambol. Clearly people moving between time zones are screwed; they should get devices which have full iCalendar 2.0 and time zone support and use the corresponding servers... > > 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? > Evolution does skip occurences in EXDATE VALUE=DATE for daily, weekly, yearly. Then the fix with stripping the time may work. > > 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. > But how to judge whether time information coud be stripped? Actually there is > no hourly recurrence category. It is used for daily, weekly, monthly and > yearly > recurrence to match exdate and event more precisely(compare date and time). If there is no hourly recurrence, can we have more than one repeating event per day and then filter out more than just the wanted recurrences when removing all on that day (TYPE=DATE) instead of a specific one (TYPE=DATE-TIME)? I can think of situations (standard<->daylight saving changes) where the same local hour occurs more than once. But how would that be treated by a daily recurrence during that double hour? Occur once or twice? How could one of the two recurrences be removed, but not the other? Interesting, but not particularly productive questions ;-) I think we can safely ignore such subtleties because they'll be very rare. We should limit the fix in the incoming script to peers talking vCalendar 1.0, following the rationale that "proper" peers don't need their data mangled. -- 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
