Major Possible Update: Support For Times.

[aekanshd]

We're using Django-Recurrence in a production server, and we largely deal with events. We would like to see a DateTime field instead of a DateField alone so it becomes hugely easier to tackle trickier issues like timezone conversion, and event management. Please feel free to give an explanation as to why this wasn't the design initially thought of.

Larger issue: We're using the recurrence field along with a TimeField in our project but the problem is that the TimeField in Django is not TimeZoneAware which causes weird and sometimes bizarre errors. We've tried our best to fix the issue but I think it's high time django-recurrence supported DateTime instead of just a Date.

[duduklein]

@aekanshd , the RecurrenceField is actually a TextField not a DateField as far as I understand.

According to dateutil, each rule could have a dtstart which is an aware datetime. In this package, this dtstart can be set generally for the ruleset, but not per rule. I don't know why the author made this choice.

I'm also using a TimeField alongside the RecurrenceField, but this means that I would need to duplicate this in order to have more than one specified time in a ruleset, with bothers me. I have a need to create a recurrence ruleset that would happen every weekday at 9am and 3pm.

I can accomplish this with 1 vanila dateuitl ruleset, but not with 1 django-recurrence ruleset, since I can only associate one time (either 9am or 3pm). I would need 2 django-recurrence rulesets with one time each and would need to get the earliest of the 2 occurrences every time which would alternate between the 9am and 3pm rules. I would prefer to take advantage of dateutil's algorithm only...

I'm considering abandoning this package because of this. I have created a vuejs frontend for my endusers with https://github.com/jakubroztocil/rrule js library which is inspired by dateutil.

[duduklein]

@aekanshd some other thoughts about this :

I looked at the dateutil library directly to check the datetime support. As the RFC 5545 specifies every rule has its own DTSTART property which gives the time as we want. There is one drawback though. In dateutil every component of the ruleset, including and excluding rules and dates, must be of the same type.

So if you have an including rule which specifies a certain time, if you want to exclude a specific day, you need to enter that day with the same specific time. Otherwise, you get an error. I have also chimed in a discussion there regarding this issue.

@dominicrodger seems to have "solved" this issue in this package imposing the fact that only one time is allowed. One dtstart is passed independently from all the rules and if you look at the code, when this package converts its ruleset to dateutil's ruleset, it passes the same dtstart to all rules and dates (including and excluding ones).

As my understanding, this package offers a great admin widget (I did not test the regular non-admin widget) and an abstraction of times making us work with date only for the rules and inserting the same time information for all rules/dates.

@dominicrodger , can you chime in and shed some light on it ?

[dominicrodger]

Hi @duduklein - I don't have a lot of light to shed here unfortunately - your assertion that this library deals with dates only is correct - where I've used it I just add a separate field for time on the model, I've never needed anything more complicated than that.

I don't actually use this library now - so my support here is mostly just merging fixes where I am comfortable with them, and pushing releases to PyPI. If someone else wants to take over ownership, I'd be more than happy to hand it over.