Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • K KCalendarCore
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 2
    • Issues 2
    • List
    • Boards
    • Service Desk
    • Milestones
  • Bugzilla
    • Bugzilla
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • FrameworksFrameworks
  • KCalendarCore
  • Merge requests
  • !53

Implement period support in RDATE

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Damien Caliste requested to merge work/dcaliste/period into master Aug 31, 2021
  • Overview 15
  • Commits 1
  • Pipelines 0
  • Changes 13

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.

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: work/dcaliste/period