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 request: filtering an an icalendar object with between #109

Open
natashamm opened this issue Feb 10, 2023 · 5 comments
Open

Feature request: filtering an an icalendar object with between #109

natashamm opened this issue Feb 10, 2023 · 5 comments

Comments

@natashamm
Copy link

natashamm commented Feb 10, 2023

Instead of returning a list of events like recurring_ical_events.of(an_icalendar_object).between(day 1, day 2), return the original icalendar_object with all the events outside of past, future removed.

That would mean for a VEVENT with an RRULE that has some events taking place outside of day 1 - day 2, modifying the RRULE.

I might be interested in working on this too.. I just also wanted to start a discussion to get your expertise and input to see if 1) this is something that has already been attempted before, 2) if this even something that this library would want to support, and 3) maybe this functionality exists and I am missing it!

Thanks!


We're using Polar.sh so you can upvote and help fund this issue. We receive the funding once the issue is completed & confirmed by you. Thank you in advance for helping prioritize & fund our work. Fund with Polar
@niccokunzmann
Copy link
Owner

Hi, thanks for posting! This sounds interesting..

I think about it in the terms of testing: A lot of the tests can run on your code, too to make sure it is working.

  1. This was not discussed before here to my knowledge. 3) You can not see it because it is not there. I think, you miss having it, though :)
  2. I am happy to support you on this and you can integrate it. You can also choose to fork or reuse code under the license. From a user perspective, it makes sense, to be able to choose the return value: list or calendar.

Thinking about it this way, the strategy pattern comes to my mind: This strategy object is the choice between list generation and calendar. This would also path the way towards solving #103 and #90 from my perspective.

For me, TDD is important but you do not have to do it. If your code is tested 100% though, other people will not break it in the future and provide fixes to the little bits we missed.

What do you think?

@natashamm
Copy link
Author

Hi thanks for your feedback/input.

That sounds good, I will leave updates in the thread when I have something more to share!

@niccokunzmann
Copy link
Owner

I might be slow but still, you can let me know. You can also create a PR as soon as you have just a little code, so I can have a look.

@niccokunzmann
Copy link
Owner

I just wondered: This could be called constrain(start, stop=None).
The easiest implementation I would think of is this one:

  1. remove RRULE, RDATE, EXDATE
  2. create RDATE entries for the repeated components with the same UID.

There is a case to consider for edited events.

@niccokunzmann
Copy link
Owner

Ok, to make it a valid RFC5545 calendar that can be exported as an ICS file that also allows all the events of one type to actually show up as related (same UID), I propose this:

  1. Add a method constrain(start, stop) that returns an icalendar.Calendar.
  2. Use between() to get all the events.
  3. Remove all the subcomponents that are used (e.g. VEVENT) from the calendar.
  4. For each UID, there is one event that gets all other events' DTSTART as an RRULE
  5. a copy of each but the first event of a certain UID with RECURRENCE-ID is added to the calendar as well.

This seems to be a start for an algorithm.

Another one would be to modify RRULE and RDATE. For that, one might need to dig a bit deeper into the code.

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