Wrong weekday range

[agileshaw]

The weekday range should be 0-6 as specified in Cron. However, croniter is accepting 7 as a valid weekday value.

Current:

>>> from croniter import croniter
>>> croniter.is_valid("* * * * 7")
True
>>>

Expecting:

>>> from croniter import croniter
>>> croniter.is_valid("* * * * 7")
False
>>>

The line causing the error seems to be: https://github.com/kiorky/croniter/blob/4d6bb9747ddaaaf5cf44af7e4e821065cf9969fa/src/croniter/croniter.py#L140

[kiorky]

Well, 7 is an alias to day 0, see: https://github.com/kiorky/croniter/blob/3.0.4/src/croniter/croniter.py#L221
This is an old feature that i never was fond of, but the project is now dead.

I removed it in already released 4.0.0 to stick to standard cron.

[gibsondan]

Chiming in in support of the previous behavior after we got at least one bug report after upgrading - That same wiki page from the original post here indicates that 7 is allowed on some systems, and I think most Linux crontabs support it.

[WillDaSilva]

I'll add that we can't change how our library handles cron expressions without making a major version bump ourselves. To avoid that, but still upgrade to croniter v4, we'll have to add code that replaces 7 in the day-of-week field with 0 works around 7 not being supported.

I haven't fully thought through whether having the 7 be an alias for 0 is a good idea in a greenfield project, but since this isn't a greenfield project, and instead has many users, the upgrade to croniter v4 will likely cause bugs in lots of software that uses it, or else impose a burden as everyone who uses it who doesn't want to break things has to implement workarounds to preserve the historical behaviour.

Regardless, @kiorky, you have my thanks for maintaining this useful project.

[gibsondan]

(+1 re: thanks!)

I thought about swapping in 0 for 7 as well but wasn't immediately sure if that would break "6-7" or not, haven't had a chance to test to confirm yet. Maybe swapping in the day of the week strings (6 => Sat, 7 = Sun, etc.)?

[kiorky]

I'll add that we can't change how our library handles cron expressions without making a major version bump ourselves. To avoid that, but still upgrade to croniter v4, we'll have to add code that replaces 7 in the day-of-week field with 0 works around 7 not being supported.

On that specific point, please note that a major version bump has been done, 3->4.

[kiorky]

I thought about swapping in 0 for 7 as well but wasn't immediately sure if that would break "6-7" or not, haven't had a chance to test to confirm yet. Maybe swapping in the day of the week strings (6 => Sat, 7 = Sun, etc.)?

If you had took the time to read last changelog, and last changesets along that release, you would have been insured of what behavior to expect around the SUNDAY ranges which indeed need particular care.
You can refer to the https://github.com/kiorky/croniter/blob/4.0.0/src/croniter/tests/test_croniter.py#L1979 test_sunday_ranges_to & test_sunday_ranges_from tests to know what to expect.

As of today, Sat-Sun or 6-0 would work meaning saturday followed by the nearest sunday, but not 0-6 as this would mean each day of week.

[kiorky]

So as asked, DOW7 behavior is restored, and now documented and will stay as-is.
Also, ranges calculation have again been reworked to support all backtracking expressions (sat-sun, wed-sun, apr-dec, apr-feb, etc).
Please see documentation and tests added in 5.0.1: 4.0.0...5.0.1