Thu Jun 17 20:56:13 UTC 2021 - Dirk Müller <dmueller@suse.com>
- update to 1.0.13:
* Fix ZeroDivisionError with ``* * R/0 * *``
* Add support for hashed/random/keyword expressions
* Review support support for hashed/random/keyword expression and add expanders reactor
* fix bug: bad case:``0 6 30 3 *``
* Create ``CroniterUnsupportedSyntaxError`` exception for situations where CRON syntax may be valid but some combinations of features is not supported.
This *may* impact existing cron expressions in prior releases, because ``0 0 * * 15,sat#1`` was previously allowed but incorrectly handled.
* Update ``croniter_range()`` to allow an alternate ``croniter`` class to be used. Helpful when using a custom class derived from croniter.
Thu Nov 26 09:22:47 UTC 2020 - Dirk Mueller <dmueller@suse.com>
- update to 0.3.36:
- Updated docs section regarding ``max_years_between_matches`` to be more shorter and hopefully more relevant.
- Add a new initialization parameter ``max_years_between_matches`` to support finding the next/previous date beyond the default 1 year window, if so desired. Updated README to include additional notes and example of this usage. Fixes #145.
- The ``croniter_range()`` function was updated to automatically determines the appropriate ``max_years_between_matches`` value, this preventing handling of the ``CroniterBadDateError`` exception.
- Updated exception handling classes: ``CroniterBadDateError`` now only
applies during date finding operations (next/prev), and all parsing errors can now be caught using ``CroniterBadCronError``. The ``CroniterNotAlphaError`` exception is now a subclass of ``CroniterBadCronError``. A brief description of each exception class was added as an inline docstring.
- Updated iterable interfaces to replace the ``CroniterBadDateError`` with ``StopIteration`` if (and only if) the ``max_years_between_matches`` argument is provided. The rationale here is that if the user has specified the max tolerance between matches, then there's no need to further inform them of no additional matches. Just stop the iteration. This also keeps backwards compatibility.
Thu Mar 7 13:48:40 UTC 2019 - Tomáš Chvátal <tchvatal@suse.com>
- Update to 0.3.27:
* Handle -Sun notation
* Handle invalid ranges correctly
* Pypi hygiene
* fix get_next while perserving the fix of get_prev
* Don't count previous minute if now is dynamic If the code is triggered from 5-asterisk based cron get_prev based on datetime.now() is expected to return current cron iteration and not previous execution.
