search

siebertm / parse-cron

parses cron expressions and calculates the next occurence after a given date
MIT License
147 stars 57 forks source link

Bad calculation #28

Open jmlfr opened 8 years ago

jmlfr commented 8 years ago

There is a bad calculation if I set more complex crontab. Here is an example.

2.2.4 :001 > require 'cron_parser' => true 2.2.4 :002 > require 'time' => true 2.2.4 :003 > cron_parser = CronParser.new('1 2 8-15 * 4') => #<CronParser:0x000000009644e8 @source="1 2 8-15 * 4", @time_source=Time> 2.2.4 :004 > cron_parser.next(Time.parse('2016-03-01 00:00')) => 2016-03-03 02:01:00 +0100

It should be '2016-03-10 02:01:00' I think.

meesterdude commented 8 years ago

in the codebase: 

# Careful, if both DOW and DOM fields are non-wildcard,
# then we only need to match *one* for cron to run the job

I would actually like to know why it does this - I get mixed results when i test the cron online between when trying to identify should be correct. What I do know is in the current operation, I can't define a rule for friday the 13th because it matches the next friday, OR the 13th; which I don't understand being desireable.

@siebertm can you shed some light on the reasonings?

meesterdude commented 8 years ago

Actually, that appears to be the spec! that's just wild. So the logic is "the first, the 15th, or any friday" scheduling wise - I don't know why I'd want that. Or anyone. Meanwhile if it were AND, you could do things like "the first tuesday of the month".

I'll take a look at adding a flag to support the variation for those of us who want it to facilitate this kind of behavior while leaving the default behavior to meet the spec - and call out the subtly in the docs.

meesterdude commented 8 years ago

see #29

jmlfr commented 8 years ago

Thanks a lot for patch, I'll try it ASAP ! :)