Closed leemurus closed 3 years ago
What schedule are you trying to express ?
Valid format does not implicitly mean that your expression is a valid cron.
May you test your expression on https://crontab.guru/ ?
I have a frontend and a backend. The frontend validates the cron expression against the standard, and the backend should do the same.
Valid format does not implicitly mean that your expression is a valid cron.
Does this mean I cannot use your library to validate the cron expression?
In documentation you wrote that this method validate crons
You can validate your crons using is_valid class method. (>= 0.3.18):
Your expression has a valid and LEGIT format but has no real meaning.
That's aint croniter purpose to replace your brain.
Surely, croniter can validate (ONLY UNIX) cron expressions and lot of user are using it for that purpose.
croniter can validate (ONLY UNIX) cron expressions It can validate only "format" correctness (not "cron expression" correctness), its better to clarify that in the documentation, but it is ok. 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'). Looks like a bug, right ?
it aint a bug, a cron expression can be syntactically correct, but have no range.
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 said in the first place, the OP said in the first place that is_valid returns True which is legit.
Hello, everyone. I found a bug at work and it is related to the validation of the cron expression. I have 0 days and 0 months, but your method says "True". Can you explain to me if i'm wrong?