Notes on Standard Compliance

khal tries to follow standards and RFCs (most importantly RFC 5545 iCalendar) where ever possible. Known intentional and unintentional deviations are listed below.

Recurrent events with RDATE;VALUE=PERIOD

RDATE s with PERIOD values are currently not supported, as icalendar does does not support it yet. Please submit any real world examples of events with RDATE;VALUE=PERIOD you might encounter (khal will print warnings if you have any in your calendars).

Recurrent events with RANGE=THISANDPRIOR

Recurrent events with the RANGE=THISANDPRIOR are and will not be [1] supported by khal, as applications supporting the latest standard MUST NOT create those. khal will print a warning if it encounters an event containing RANGE=THISANDPRIOR.

[1]unless a lot of users request this feature

Events with neither END nor DURATION

While the RFC states:

A calendar entry with a "DTSTART" property but no "DTEND"
property does not take up any time. It is intended to represent
an event that is associated with a given calendar date and time
of day, such as an anniversary. Since the event does not take up
any time, it MUST NOT be used to record busy time no matter what
the value for the "TRANSP" property.

khal transforms those events into all-day events lasting for one day (the start date). As long a those events do not get edited, these changes will not be written to the vdir (and with that to the CalDAV server). Any timezone information that was associated with the start date gets discarded.

Note

While the main rationale for this behaviour was laziness on part of the main author of khal, other calendar software shows the same behaviour (e.g. Google Calendar and Evolution).