> Why does get_next() return a real day for the incorrect cron expression? (1 jan for '0 0 0 0 0')

[mikhail-kashirskii]

But the question is - why does get_next() return a real day for the incorrect cron expression? (1 jan for '0 0 0 0 0')

This is not what the OP saidf in the first place, the OP said in the first place that is_valid returns True which is legit.

Originally posted by @kiorky in #5 (comment)

[kiorky]

expected and historic behavior or croniter: https://github.com/kiorky/croniter/blob/master/src/croniter/croniter.py#L108

day=0 and month=0 are aliased and expanded to day=1 month=1

[kiorky]

( this was at the time of the write to support most UNIX expressions formats in the wild, see https://en.wikipedia.org/wiki/Cron)

[mikhail-kashirskii]

Sorry, I don't see any format that takes 0 as month. Could you please point to that explicitly?
Or its just an undocumented croniter feature, right?

[kiorky]

it's not for months but to support seconds repeat where in this case, fields are then shifted up to 6 and the 4th field becomes the day one.

As this case is pretty straightforward, i added some rule to check in in the new released croniter==1.1.0

Believe me, cron corner cases are infinite and using misformed crontabs expression will still always give you opportunity for bad ranges.

[mikhail-kashirskii]

Thanks a lot!