Repeating events about gettogether

[mhall119]

How far into the future would you need them to exist? Just the next one?

[craigmaloney]

I think four events in the future would be good, with the next one created when the first one ends.

eg:

1/2, 1/3, 1/4, 1/5

On 1/3 there would be:
1/2,, 1/3, 1/4, 1/5, 1/6

etc.

[mhall119]

Putting this here for later reference, it looks like it would be useful in adding this feature:
https://django-recurrence.readthedocs.io/en/latest/usage/index.html

[mhall119]

Bumping this to 0.4.0 because I couldn't get django-recurrence working in Django 2.0, looks like this is going to require some debugging or upstream fixing

[deutrino]

There are timezone-related dragons lurking here; see #59 for discussion, and the section on recurring events in https://www.w3.org/TR/timezone/

[mhall119]

Hi guys,
I'm trying to decide how to implement recurring events. My options are to (1) add the recurrence information to a regular Event object, and create new Event objects based on that, or (2) create a RepeatingEvent model to store the recurrence information and act as a template for creating new Event objects.

The problem with (1) is that I'll end up with multiple Event records with the same recurrence information, which means I'd have to ignore all but one. Or I can leave it off all but the first, in which case deleting the first will delete the recurrence info also, and you'd have to change the first event to change the recurrence info.

The problem with (2) is that I will duplicate data between the "template" event and the real ones, and when exporting the recurrence info to iCal I would have to make sure to set it's start date to the next recurrence after the latest Event object created from it.

I'm leaning towards (2) right now, but I'm hoping to get your feedback and advice from our experiences doing similar work.

[craigmaloney]

I think (2) makes sense, in part because it's essentially a sequence with a start date and a stepping mechanism. Creating the events in the future may cause issues if the repeating events change for whatever reason.

(and yes, this goes against what I said earlier. I'm OK with changing my mind. ;) )

[deutrino]

Keep in mind the use case where an event typically occurs every Wednesday, but two months from now it'll be on Thursday, or won't happen at all that week, etc. Users will definitely need to make one-off changes to events in a series.

[mhall119]

Every actual event will be it's own Event instance, so that won't be a problem you can move it or cancel it or whatever. I'll just have to have a way to make sure the event repeater knows it's part of that series even if it's been moved, so it doesn't try to recreate it.

[deutrino]

I am struggling to remember the implementation details of the software I worked on, possibly due to the pain involved, but a one-to-many, "EventSeries has one or more Events" foreign key relation seems a safe bet, as long as you can reverse it from the Event?