[Ietf-calsify] (no subject)
reinhold at kainhofer.com
Wed Oct 13 06:56:56 PDT 2004
On Wednesday 13 October 2004 14:45, Helge Hess wrote:
> On Oct 13, 2004, at 14:33, <Veikko.Punkka at nokia.com> wrote:
> > I agree, it would be _really_ useful to have a (maintained) chart
> > which outlines what RRULE features are supported by what
> > implementation.
Yes, I'd like to have such a table too. Here's the current support of KDE
(libkcal as the base library, which supports more than KOrganizer as the
corresponding GUI. libkcal is also used by other applications like KPilot's
calendar conduits, the time tracking application KArm, and KNotes). I'll have
to distinguish betwen KOrganizer (which provides less gui options) and
libkcal (which supports almost all BY* rule, although you cannot create them
libkcal does understand and can handle the following BY* rules (not all
combinations are understood, though. The ones neede by korganizer below are
of course best supported):
BYSETPOS: No (but is planned, needed for first/last weekday of a month)
In KOrganizer's GUI we support the following recurrence options:
-) on the n-th (mon|tues|..)day: BYDAY=...
-) on the n-th day: BYMONTHDAY=...
-) On the n-th day of month Y: BYMONTHDAY=11;BYMONTH=10
-) On the n-th (mon|tues|..)day of Month Y:BYDAY=2MO;BYMONTH=10
-) On the n-th day of the year: BYYEARDAY=285
All other recurrence rules understood by libkcal are shown in KOrganizer (if
the FREQ>=DAILY), but cannot be edited.
> > Based on that chart it would be possible to make a
> > rational
> > choice of which RRULE features belong to the core specification and
> > which ones not.
> I think its already more or less clear that RRULE needs to be removed
> completely from the core spec so that we can move to UTC for the base
Why is it so clear that RRULE needs to be removed? Sure, moving to UTC would
be great, but recurrence rules are such a core feature to (almost) all
calendar GUIs, that I don't think sacrificing rrules for UTC is really
For pure invitation handling, RRULEs might not be absolutely necessary, but
remember that many applications use iCalendar as their native storage format
(for example, KOrganizer, Evolution, KPilot's calendar conduits, etc.).
I think it really depends on whether iCalendar is supposed to be a format
purely intended for invitation handling, or also as a storage format.
Currently, I think it's the latter, and there removing all recurrence rules
in the core spec is like removing all paragraph format settings in a word
processing format spec.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041013/eab276e5/attachment.bin
More information about the Ietf-calsify