You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
RFC 5545 states, that
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:
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.
The text was updated successfully, but these errors were encountered: