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

List:       kde-pim
Subject:    Re: [Kde-pim] Korganizer Ical Issues
From:       Reinhold Kainhofer <reinhold () kainhofer ! com>
Date:       2004-07-12 18:27:49
Message-ID: 200407122027.50293.reinhold () kainhofer ! com
[Download RAW message or body]

Am Montag, 12. Juli 2004 17:40 schrieben Sie:
> 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.

At least it seems to import yours. Outlook completely refuses to import 
our .ics files (http://bugs.kde.org/show_bug.cgi?id=40933).



> > 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.

No, P1D is the correct duration. We fixed the end date to be non-inclusive but 
missed to fix the duration (since korganizer doesn't use them, we don't have 
test cases).

> > > 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

Oops. But then, korganizer doesn't make use of BYSETPOS anyway, so it's just a 
wrong loading (we are using libical and our own C++ wrapper library called 
libkcal).

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

Yes, seems like it.

> > > 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. 

yes, that's also what rfc 2445 says. See section 4.6.1:
   The "DTEND" property for a "VEVENT"
   calendar component specifies the non-inclusive end of the event.

> 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...

Yes, sadly, the display time zone and the time zone of the event are not 
necessarily the same (not even the same as the local time). The problem with 
storing the original tz is what to present to the user for editing the event? 
Of course he expects to be able to edit the event in his local time zone. But 
then the recurrence rule first needs to be shifted to the display time zone, 
and afterwards it would need to be shifted back to the event's orginal time 
zone, which can get really nasty :-((


> 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.

;-)) 
Yes, given that a even calendaring app by the company of one of the two 
authors even didn't get it right (e.g. they got the minus of the trigger 
attribute of valarms completely wrong, etc.), you might be right.

> 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.

No problem, it was just ment as a general call for help. 

From your tests it seems you have a lot of test cases in iCalendar format... 
Currently, we don't have any test files for korganizer, and only five simple 
test cases for our iCalendar library.

Cheers,
Reinhold
_______________________________________________
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]