Currently the PERIOD definition of RDATE is not implemented (and one user stumbled on it, see https://forum.sailfishos.org/t/sailfish-community-news-26th-august/7688/9).
It is defined in the RFC5545, see https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.5.2 and can be used instead of exceptions to define recurring occurrences with a different duration than the parent incidence.
I'm proposing an implementation trying to get it working with minimal changes in the Recurrence class while keeping it API compatible with RDATE being only date or date times. The idea is based on the fact that PERIOD is also defining a starting date, like a DATETIME RDATE, so we can save this part directly using the addRDateTimes() method and be sure that all methods using the mRDateTimes array to calculate occurrences, and so on will continue to work, even with PERIOD definitions. Then, the duration (or end date time) provided by the PERIOD is stored in a new QHash that makes the link between the starting date time and a Period object. The new API thus allow to:
- add a new RDateTime as a Period object,
- inquire if a given occurrence date time is associated to a period or not.
Finally, to make this simple for code using this, I'm proposing to hide the fetching of the period in the OccurrenceIterator by adding a occurrenceEndDate() method that do it internally and fallback to sensible values if not (either the type does not allow end time, like journals, or a new end time is computed for the given occurrence based on the duration of the parent).
Of course, serialisation and deserialisation to and from iCal format is implemented.
I've extended tests for all new methods and implementations, in testtimesininterval, testoccurrenceiterator and testicalformat.
@winterz what do you think ? Feel free to invite other reviewers also so we can discuss the propose new API and implementation.