Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Check whether calendar is within defined range, i.e. DTSTART in sync with RRULE #407

Closed
minichma opened this issue Jun 18, 2018 · 0 comments

Comments

@minichma
Copy link
Collaborator

RFC 5545 states, that

The recurrence set generated with a "DTSTART" property value that doesn't match the pattern of the rule is undefined.

Events not following this suggestions are therefore allowed but undefined. Different libraries seem to handle the case differently and within Ical.net we sometimes have the includeReferenceDateInResults parameter to specify the intended behaviour and sometimes we don't.

To avoid confusion, it would sometimes be desirable to reject ICALs with an undefined constellation.

This feature request suggests introducing functionality for easily checking, whether an ICAL is within defined range, e.g. by introducing a function like CalendarEvent.IsWithinDefinedRange().

Regarding the prementioned DTSTART aspect, we could implement a check like the following:

public static bool IsWithinDefinedRange(this CalendarEvent evt)
{
    if (evt.RecurrenceRules != null)
    {
        foreach (var rrule in evt.RecurrenceRules)
        {
            var ev = new RecurrencePatternEvaluator(rrule);
            var startUtc = evt.DtStart.AsUtc;
            var occurrences = ev.Evaluate(evt.DtStart, startUtc, startUtc.AddSeconds(1), false);
            if (!occurrences.Select(x => x.StartTime.AsUtc).Any(x => x == startUtc))
                return false;
        }
    }

    return true;
}

However, this doesn't work in the current version due to #406 and there probably is a more efficient way of checking this and having a more comprehensive check (possibly covering for other undefined states too) within the lib would certainly be beneficial.

There also seem to be a couple of other issues related to this one, including #371, #242, #142.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants