Utility for working with recurring dates in Django.

Last update: Jan 6, 2023

Related tags

Overview

django-recurrence

django-recurrence is a utility for working with recurring dates in Django. Documentation is available at https://django-recurrence.readthedocs.org/.

It provides:

Recurrence/Rule objects using a subset of rfc2445 (wraps dateutil.rrule) for specifying recurring date/times;
RecurrenceField for storing recurring datetimes in the database;
JavaScript widget.

RecurrenceField provides a Django model field which serializes recurrence information for storage in the database.

For example - say you were storing information about a university course in your app. You could use a model like this:

import recurrence.fields

class Course(models.Model):
    title = models.CharField(max_length=200)
    start = models.TimeField()
    end = models.TimeField()
    recurrences = recurrence.fields.RecurrenceField()

You'll notice that I'm storing my own start and end time. The recurrence field only deals with recurrences not with specific time information. I have an event that starts at 2pm. Its recurrences would be "every Friday". For this to work, you'll need to put the recurrence application into your INSTALLED_APPS

Running the tests

Our test coverage is currently fairly poor (we're working on it!), but you can run the tests by making sure you've got the test requirements installed:

pip install -r requirements_test.txt

Once you've done that, you can run the tests using:

make test

You can generate a coverage report by running:

make coverage

You can run tests on multiple versions of Python and Django by installing tox (pip install tox) and running:

tox

Comments

Flexible handling of dtstart incl. documentation
As stated by @jpulec in #90 dtstart is handled according to RFC 2445 so that it always counts as the first occurrence regardless of your pattern, like when used with between(). This causes confusion for some users (e.g. #36, #50, #71) because it is in conflict with how dateutil.rrule handles dtstart.

With this pull request I suggest a solution which consists of:

The addition of an optional parameter include_dtstart which can be either passed to a RecurrenceField or a Recurrence instance. With include_dtstart=False the default behavior does not occur for the field/object so that dtstart no longer finds its way into the occurrence list if it does not match your recurrence pattern. Because the default behavior doesn't change if include_dtstart is not specified backward compatibility is ensured.

A clear documentation of how django-recurrence handles dtstart and how it can be controlled with the feature described above. In that way further confusion should be prevented.

Some additional unit test cases.

Enhancement Changes Needed
opened by denisiko 21

Widget js is raising errors

Using the minimal Course model from the docs, I've created the following template, and a suitable create view and model form to match:

<!DOCTYPE html>
<html lang="en_US">
<head>
  {{ form.media }}
</head>

<body>
  <h1>Create Course</h1>

  <form action="" method="post">{% csrf_token %}
    {{ form.as_p }}
    <input type="submit" value="Submit" />
  </form>
</body>
</html>

However, when actually accessing this view, I see these three errors show up in Firebug, and the recurrence field is rendered as just a plain text input.

ReferenceError: django is not defined
    if (!django.catalog) {
ReferenceError: gettext is not defined
    'inclusion': gettext('including'), 'exclusion': gettext('excluding')
TypeError: recurrence.display.labels is undefined
    recurrence.display.labels.add_rule, {

This is using django-recurrence==1.0.3, pip installed from PyPI.

opened by jbradberry 19

How Does this Library Handle dtstart?

It isn't stated clearly in the docs anywhere, and it seems like there are conflicting opinions in both how this library handles dtstart. In the docstrings for base.py and Recurrence it does seem to indicate that dtstart is handled the according the RFC 2445, which uses it as both the starting point for recurrences and as the first recurrence returned.

This is in contrast to how dateutil.rrule handles it, which just uses dtstart as the starting point for recurrences and does not automatically add it as the first occurrence.

It looks like this can be a bit of a pain point for users. #50 #36

Should this be better documented somewhere, to explicitly state that it doesn't follow the way dateutil.rrule handles dtstart and follows more closely to the spec. Or should changing the behavior be considered since it appears to cause issues? I recognize that this would be a big change.

opened by jpulec 15
change default dtstart to midnight and annual/bymonth recurrence to DAILY

Not sure what you think of these changes.

The first commit makes it easier to test rulesets for a particular date by specifying the default time as (0,0) (instead of whatever now() was when the rule was created).

The second commit makes it possible to test whether a datetime exists within an annual recurrence when only the month (but not a specific day of the month) is selected. I think this is more transparent to the user, since otherwise the particular date of the recurrence on a given month is hidden.

opened by yekibud 14
Add start date in a rule in admin widget
Hi,

i want to set event recurrences in the admin widget with a start date but i dont find how to do this, start date of my rules automatically take a datetime.now()

from datetime import datetime import recurrence myrule = recurrence.Rule( recurrence.DAILY ) pattern = recurrence.Recurrence( dtstart=datetime(2015, 10, 2, 0, 0, 0), dtend=datetime(2015, 10, 9, 0, 0, 0), rrules=[myrule, ] )

It thats i want, i got an event started a 2october with daily recurences to 9 october, i check to python dateutil and its easy to do this directly with it too. In your app i really enjoy the admin widget, my users can easy enter complex recursive events with it, but if they can't set a start date will difficult.

in recurrence.fields we can see this : " Field that stores a recurrence.base.Recurrence object to the database."

Ok i go in base.Recurrence i see this :

`dtstart` : datetime.datetime Optionally specify the first occurrence. This defaults to `datetime.datetime.now()` when the occurrence set is generated.

Im in this case, it generate me an automatic start date.

In recurrences.forms.RecurrenceField :

`accept_dtstart` : bool Whether to accept a dtstart value passed in the input.

Im really confuse, how to set a dtstart in the input?

Thanks for your help
opened by V1ce 13
Recurrence only working in Admin but buttons don't do anything when I use it in Model Form

Django admin has been fully functional with the package. However, when I tried to integrate it into a model form, the buttons don't do anything when I click them... Any help on this would be great because I've been stuck on this issue for days now with no luck!

opened by wolfhound115 12
Fix timezone problems in django admin widget

tl;dr: I think it fixes the problem that #71 is trying to address, but in a simpler and more idiomatic way.

What is the problem?

My browser is in timezone GMT+2. If I select the 15th of October in the widget, the Javascript in the current implementation will create the following datetime object:

2017-10-15T00:00+02:00

This is midnight in my timezone, but in UTC, this is actually still 10pm on the 14th! Now, somewhere on the way to the django database, the timezone information gets stripped away and what is stored is the time in UTC, without saying that it is UTC:

2017-10-14T22:00

Clearly, this is a bug because we are on the wrong date: 14th of October instead of 15th.

As far as I can see convention of this library appears to be that we store the timezone-agnostic date by storing a timezone-agnostic datetime with the time set to midnight. This result is clearly violating this convention.

How does this PR fix this?

This PR fixes it by making sure that the widget creates the following datetime object instead:

2017-10-15T02:00+02:00

This is 2 am in my timezone, but in UTC, this is actually midnight

So, when the timezone information gets stripped during form submission, the resulting timezone-agnostic datetime that ends up in the database is

2017-10-15:00:00

The 15th is the date that the user clicked. Since we are operating timezone-agnostic, this is all we can ask for. Happy end :)

opened by KonstantinSchubert 10
Fixes #87

This is my attempt at fixing this long-standing issue. It works for my needs without issues so far. I've utilized MutationObserver for observing DOM node additions. And replaced Django render method with a javascript initialization instead.

opened by pasevin 9
Declare dependency on the admin's jQuery.js
Without this change, the admin loads recurrence-widget.init.js before jquery.init.js. As a consequence, the django.jQuery variable isn't created yet and the following error happens:

Uncaught TypeError: django.jQuery is not a function at recurrence-widget.init.js:1

With this change, the admin loads JS scripts in the correct order.

Refs #142.
opened by aaugustin 8
Will there be any support for django 2.2 and above?
Do you plan on any updates so that current versions of django will be supported? I have been trying and hoping to get this to work with 2.2 and just re-read the documentation to find this...

Currently, django-recurrence supports Python 2.7, Python 3.3, Python 3.4 and Python 3.5. django-recurrence works with Django from versions 1.7 to 1.11.

It appears that {{form.media}} is loading enough to create the textarea but that is it.
opened by apowell656 8
Passing a null value to RecurrenceField will cause a TypeError

At this point in the code https://github.com/django-recurrence/django-recurrence/blob/master/recurrence/forms.py#L147 if the value you passed is None it will throw a TypeError, saying it expected a string or a buffer. Maybe a check should be done, if value is None then value = '' the empty string

opened by audiolion 8
Bump sphinx from 4.3.2 to 6.1.1
Bumps sphinx from 4.3.2 to 6.1.1.

Release notes

Sourced from sphinx's releases.

v6.1.1

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v6.1.0

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v6.0.1

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v6.0.0

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v6.0.0b2

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v6.0.0b1

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v5.3.0

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v5.2.3

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v5.2.2

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v5.2.1

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v5.2.0

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v5.1.1

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v5.1.0

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v5.0.2

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v5.0.1

Changelog: https://www.sphinx-doc.org/en/master/changes.html

v5.0.0

No release notes provided.

v5.0.0b1

Changelog: https://www.sphinx-doc.org/en/master/changes.html

... (truncated)

Changelog

Sourced from sphinx's changelog.

Release 6.1.1 (released Jan 05, 2023)

Bugs fixed

#11091: Fix util.nodes.apply_source_workaround for literal_block nodes with no source information in the node or the node's parents.

Release 6.1.0 (released Jan 05, 2023)

Dependencies

Adopted the Ruff_ code linter.

.. _Ruff: https://github.com/charliermarsh/ruff

Incompatible changes

#10979: gettext: Removed support for pluralisation in get_translation. This was unused and complicated other changes to sphinx.locale.

Deprecated

sphinx.util functions:

Renamed sphinx.util.typing.stringify() to sphinx.util.typing.stringify_annotation()

Moved sphinx.util.xmlname_checker() to sphinx.builders.epub3._XML_NAME_PATTERN

Moved to sphinx.util.display:

sphinx.util.status_iterator

sphinx.util.display_chunk

sphinx.util.SkipProgressMessage

sphinx.util.progress_message

Moved to sphinx.util.http_date:

sphinx.util.epoch_to_rfc1123

sphinx.util.rfc1123_to_epoch

Moved to sphinx.util.exceptions:

sphinx.util.save_traceback

... (truncated)

Commits

77aaa86 Bump to 6.1.1 final

476c115 Suppress ValueError in apply_source_workaround (#11092)

c80d656 Bump version

4e1004a Bump to 6.1.0 final

a2176d4 Fix deprecation warnings

2c104e9 Merge branch '6.0.x'

a27d262 Bump to 6.0.1 final

821569e Add note for Pygments

222d366 imgmath: Fix relative file path (#10965)

c499f66 Add SIM113 lint (#11057)

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependencies
opened by dependabot[bot] 0
Bump tox from 3.25.1 to 4.2.4
Bumps tox from 3.25.1 to 4.2.4.

Release notes

Sourced from tox's releases.

4.2.4

What's Changed

Also accept tab after colon before factor filter expansion by @pdecat in tox-dev/tox#2823

Fail on mismatched python spec attributes by @stephenfin in tox-dev/tox#2824

Full Changelog: https://github.com/tox-dev/tox/compare/4.2.3...4.2.4

4.2.3

What's Changed

Require space after colon before factor expansion by @pdecat in tox-dev/tox#2822

Fix devenv when package for env is wheel/editable by @gaborbernat in tox-dev/tox#2820

Full Changelog: https://github.com/tox-dev/tox/compare/4.2.2...4.2.3

4.2.2

What's Changed

Remove docs about colour regression by @adamchainz in tox-dev/tox#2816

Add more c-extension env-vars to default pass_env by @gaborbernat in tox-dev/tox#2818

Full Changelog: https://github.com/tox-dev/tox/compare/4.2.1...4.2.2

4.2.1

What's Changed

update how extras are extracted to handle cases with more than 2 groups by @dconathan in tox-dev/tox#2812

New Contributors

@dconathan made their first contribution in tox-dev/tox#2812

Full Changelog: https://github.com/tox-dev/tox/compare/4.2.0...4.2.1

4.2.0

What's Changed

Introduce Upgrading doc page for tox4 by @sirosen in tox-dev/tox#2805

Document ambiguous usages in v3-to-v4 by @sirosen in tox-dev/tox#2808

Packaging inherits from pkgenv, deps and document tox 4 packaging changes by @gaborbernat in tox-dev/tox#2813

Full Changelog: https://github.com/tox-dev/tox/compare/4.1.3...4.2.0

4.1.3

What's Changed

Relax test_list_installed_deps() to allow other packages by @mgorny in tox-dev/tox#2796

Skip time-machine dep and spinner tests on PyPy by @mgorny in tox-dev/tox#2797

Reuse package_env with --installpkg by @gaborbernat in tox-dev/tox#2803

issue 2695/tox4 install command breaking change docs by @gaborbernat in tox-dev/tox#2806

Better message when command parsing on empty input by @gaborbernat in tox-dev/tox#2807

... (truncated)

Changelog

Sourced from tox's changelog.

v4.2.4 (2023-01-05)

Bugfixes - 4.2.4

- Setting ``[testenv] basepython = python3`` will no longer override the Python interpreter version requested by a factor, such as ``py311`` - by :user:`stephenfin`. (:issue:`2754`) - Also accept tab after colon before factor filter expansion - by :user:`pdecat`. (:issue:`2823`) v4.2.3 (2023-01-04)
Bugfixes - 4.2.3

devenv does not respect the specified path when the package is a wheel file - by :user:gaborbernat. (:issue:2815)

Require space after colon before factor filter expansion, unless it is the last character of the line - by :user:pdecat. (:issue:2822)

v4.2.2 (2023-01-04)

Bugfixes - 4.2.2

- Add ``CC``, ``CFLAGS``, ``CCSHARED``, ``CXX``, ``CPPFLAGS``, ``LDFLAGS``, ``PKG_CONFIG`` and ``PKG_CONFIG_SYSROOT_DIR`` to the default passed through environment variables list as these are needed for building various C-extensions - by :user:`gaborbernat`. (:issue:`2818`) v4.2.1 (2023-01-03)
Bugfixes - 4.2.1

Fix extracting extras from markers with more than 2 extras in an or chain - by :user:dconathan. (:issue:2791)

v4.2.0 (2023-01-03)

Features - 4.2.0

- Packaging environments now inherit from the ``pkgenv`` section, allowing to set all your packaging options in one place, and support the ``deps`` key to set additional dependencies that will be installed after ``pyproject.toml`` static ``requires`` but before backends dynamic requires - by :user:`gaborbernat`. (:issue:`2543`)
Improved Documentation - 4.2.0

Document breaking changes with tox 4 and packaging environments - by :user:gaborbernat. (:issue:2543)

Document how to handle environments whose names match tox subcommands - by :user:sirosen. (:issue:2728)

... (truncated)

Commits

af35384 release 4.2.4

fc289c0 Fail on mismatched python spec attributes (#2824)

af4b558 Also accept tab after colon before factor filter expansion (#2823)

f07335d release 4.2.3

4eed8d5 Fix devenv when package for env is wheel/editable (#2820)

497c17c Require space after colon before factor expansion (#2822)

36fe263 release 4.2.2

2ce4d89 Add more c-extension env-vars to default pass_env (#2818)

a906a2a Remove docs about colour regression (#2816)

43382af release 4.2.1

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependencies
opened by dependabot[bot] 0
Remove use of deprecated ‘distutils’ library

Python versions from 3.10 onward deprecate use of ‘distutils’ (in PEP 632), and it will be removed from Python 3.12.

This project should remove the option for ‘distutils’, and commit to use only the recommended ‘setuptools’ for building the package.

opened by bignose-debian 1
Saving in 'UTC' problem with DST
I don't know if #191 solves the problem.

Imagine this: server timezone is 'UTC', and user's timezone is 'Europe/Berlin' (+01:00 or +02:00 depending on the time of the year). Let's say user needs daily occurrences between 29.10. and 2.11. at 16:00h. User is creating a recurrence on 26.10. when his timezone is +02:00 compared to UTC. Current implementation will save dtstart as 14:00 UTC. And as result user would get next occurrences: 2022-10-29 14:00 UTC => 2022-10-17 16h Europe/Berlin (+02:00) 2022-10-30 14:00 UTC => 2022-10-17 16h Europe/Berlin (+02:00) 2022-11-01 14:00 UTC => 2022-10-17 15h Europe/Berlin (+01:00) 2022-11-02 14:00 UTC => 2022-10-17 15h Europe/Berlin (+01:00)

Because once the time is converted to UTC we don't know which time user wanted.

https://webis.helpshift.com/hc/en/3-pocket-informant/faq/177-recurring-events-and-daylight-saving-time-1634048685/

it should follow rule of the "creation" time zone, not server/UTC timezone,

Originally posted by @bonokl in https://github.com/jazzband/django-recurrence/issues/174#issuecomment-1325149005

one of the possible ideas can be some kind of setting attribute where user can decide whether to save all data as UTC or as it is
opened by bonokl 0
Bump flake8 from 4.0.1 to 6.0.0
Bumps flake8 from 4.0.1 to 6.0.0.

Commits

b9a7794 Release 6.0.0

b5cac87 Merge pull request #1748 from PyCQA/upgrade-pyflakes

489be4d upgrade pyflakes to 3.0.0

8c06197 Merge pull request #1746 from PyCQA/bump-pycodestyle

047e6f8 upgrade pycodestyle to 2.10

647996c Merge pull request #1744 from PyCQA/pre-commit-ci-update-config

646ad20 [pre-commit.ci] pre-commit autoupdate

b87034d Merge pull request #1741 from PyCQA/drop-py37

aa002ee require python 3.8.1+

16c371d Merge pull request #1739 from PyCQA/remove-optparse

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependencies
opened by dependabot[bot] 1
Bump pytest-sugar from 0.9.5 to 0.9.6
Bumps pytest-sugar from 0.9.5 to 0.9.6.

Changelog

Sourced from pytest-sugar's changelog.

0.9.6 (2022-11-5) ^^^^^^^^^^^^^^^^^^^

Remove py.std calls (thanks @alexcjohnson)

Commits

See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependencies
opened by dependabot[bot] 1