10:41 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=3009
--- Comment #33 from pohly <patrick.ohly(a)intel.com> 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.
4793
days inactive
4793
days old
syncevolution-issues@syncevolution.org
0 comments
1 participants
participants (1)
-
bugzilla＠moblin.org