[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    RE: [Kde-pim] Korganizer Ical Issues
From:       "George Sexton" <gsexton () mhsoftware ! com>
Date:       2004-07-12 15:40:39
Message-ID: 200407121540.i6CFefll000802 () starbug ! mhsoftware ! com
[Download RAW message or body]


> -----Original Message-----
> From: Reinhold Kainhofer [mailto:reinhold@kainhofer.com] 
> Sent: Monday, July 12, 2004 5:01 AM
> To: kde-pim@mail.kde.org
> Cc: George Sexton
> Subject: Re: [Kde-pim] Korganizer Ical Issues
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday,  12. July 2004 06:43, George Sexton wrote:
> > I have been playing with Ical interoperability and 
> encountered some issues.
> 
> Hello and welcome to the wonderful world of korganizer, and 
> all its problems and shortcomings ;-)

At least yours recurs. Evolution 1.5.9 doesn't show any of my events as
recurring. Mozilla has other problems. Outlook only supports a single Ical
entry per file, and doesn't actually import most recurrences.

> 
> > 1)	Duration Fields are improperly parsed. Using the test file, the
> > durations appear to cause problems. Reformatting the 
> duration in the 
> > file from P1D to PT1D appears to be a workaround. Per 
> section 4.3.6 of 
> > RFC-2445, P1D is compliant, not PT1D.
> 
> Yes, PT1D would not be compliant.
> However, it seems that all durations are just one day too long. E.g.
> DTSTART:20040712T000000Z
> DURATION:P1D
> means DTEND:20040713T000000Z, where July 13 should not belong 
> to the event. We fixed this for whole day events with a given 
> DTEND some time ago, maybe we just missed events with a given 
> DURATION but no DTEND...


My reading of the standard was that you had to either have a DTSTART/DTEND
pair, or a DTSTART/DURATION pair (P118 of RFC-2445). I wanted to specify
duration, but didn't think a duration of 0 would work.

> 
> Also, please note that recurring multi-day events are 
> notreally  supported by korganizer (See bug 42899: 
> http://bugs.kde.org/show_bug.cgi?id=42899)
> 
> > 2)	BYSETPOS is not handled correctly. The entries for Last Weekday,
> > don't display correctly. 
> 
> KOrganizer doesn't support last (day|weekday) of a month settings yet:
> http://bugs.kde.org/show_bug.cgi?id=79788
> 
> 
> > The RRULE for this entry is implemented precisely as the example in 
> > RFC-2445 on page 44. This issue was also reported against 
> LibICal in 
> > May.
> 
> Hmm, so a rule like
> RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
> should mean only the very last weekday of each month? 
> KOrganizer so far interprets it as the last monday, last 
> tuesday, last wednesday, last thursday and last friday. Are 
> we wrong here?

This is the rule for what you are doing:

RRULE:FREQ=MONTHLY;BYDAY=-1MO,-1TU,-1WE,-1TH,-1FR

>From RFC-2445, page 44:

   The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
   44) separated list of values which corresponds to the nth occurrence
   within the set of events specified by the rule. Valid values are 1 to
   366 or -366 to -1. It MUST only be used in conjunction with another
   BYxxx rule part. For example "the last work day of the month" could
   be represented as:

     RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1

   Each BYSETPOS value can include a positive (+n) or negative (-n)
   integer. If present, this indicates the nth occurrence of the
   specific occurrence within the set of events specified by the rule.


I think the methodolgy is to build a set of the BYDAY portion, and then
choose the last element for BYSETPOS.


> 
> > 3)	The exception date of July 28th for the Every Wednesday 
> item is not
> > interpreted correctly.
> 
> Hmm, strange. AFAIK, korganizer writes out exception dates 
> without the time, but I don't know if that's the problem.
> Can you please file a bug report at bugs.kde.org?

OK.

> 
> > 4)	Duration for Kwanzaa of 7 days doesn't work.
> 
> Here (korganizer from kde 3.3) it lasts 8 days, which is also 
> consistent with the observation of 1)

In our software, we have always handled end times as non-inclusive. Take the
following case:

A conference room is scheduled by Group A from 2:00 PM - 3:00 PM, and by
Group B from 3:00 PM - 4:00 PM. If you call end times inclusive, then you
have an overlap. In the real world, this is not how people think. People
don't think of their room booking as 2:00 PM - 2:59:59 PM, and any attempt
to make people enter them in that manner would not be successful.

> 
> > 5)	The duration for the Every Wedneday item (2 Hours) doesn't work.
> 
> Hmm, here it is shown as a two hour event (every wednesday 
> 02:00-04:00, since I'm in Central European Summer Time, GMT+1 or +2)
> 
> However, this brings us to another general problem with 
> recurring events. If you have a recurring event, say on a 
> monday 02:00-04:00 GMT, which is something like 17:00-19:00 
> on the sunday for some US timezone, which recurrence rule 
> needs to be used for this? 
> RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=SU
> or
> RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO
> 
> In korganizer we store all times in UTC (using the 
> Zulu-notation of a Z after the time), so we don't have any 
> time zone information in the calendar file. I guess in that 
> case we need the =MO version. Do you know how this should be 
> handled if you use a TZID?
> 
> See also our bug report
> http://bugs.kde.org/show_bug.cgi?id=76158

This bug demonstrates why you have to preserve the time zone information.
Say I have a recurring event, the first Monday at 10:00 PM Pacific Time
(GMT-8).  The proposed workaround is to convert to GMT and store. This is
totally broken and doesn't work. The reason is that if the event is
converted to GMT, it's time is wrong relative to the actual location. Also,
the event cannot be coerced into another time zone, because taking the case
of the 1st Tuesday, the 1st Monday is not necessarily the preceding day.

This is why the RFC specifically says in section 4.8.5.4, page 118:

   "When used with a recurrence rule,
   the "DTSTART" and "DTEND" properties MUST be specified in local time
   and the appropriate set of "VTIMEZONE" calendar components MUST be
   included."

In other words, only non-recurring events can be safely shifted to GMT.

Sadly, and unfortunately the correct answer is to preserve the timezone
data, calculate the occurrence, and then shift the time/date into the
display time zone for final display. This is singularly unpleasant, but it's
the only right answer. I have been concerned about how I will implement this
myself...



> 
> > If my iCal file is malformed, or I am mis-interpreting the 
> > specification, please let me know.
> 
> No, I don't think it's malformed. It's just that korganizer 
> handles only a subset of the iCalendar recurrence rules 
> (which can be terribly complicated, since they are designed 
> to be able to describe every rule one could possibly 
> imagine). It handles those settings very well, which it uses 
> itself, but the others (like the DURATION) are mainly untested. 

Some days I feel that the purpose of the RFC (check the authors) was to
create a standard so complex that no one would use it.
 
> One reason for this is of course, that we are very short of manpower. 
> Currently we are three people working on korganizer 
> (Cornelius, Bram and me), but only in our sparetime, which is 
> very, very, very limited for all three of us. If anyone is 
> willing to help us, feel free to speak up now ;-)
> 

Unfortunately, I am on the dark side <G>. I have a commercial calendaring
product that I work on in every spare moment. I get a lot of requests for
iCal support, and I'm trying to test with the largest number of clients that
I can.


George Sexton
MH Software, Inc. - Home of Connect Daily Web Calendar
http://www.mhsoftware.com/
Voice: 303 438 9585
 

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]