Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using minute= only assumes second='*' #259

Open
MrMathias opened this issue Oct 17, 2018 · 1 comment
Open

using minute= only assumes second='*' #259

MrMathias opened this issue Oct 17, 2018 · 1 comment

Comments

@MrMathias
Copy link

I just want to check in on this one, as I expect a different behaviour.

From the docs, we have:

# fire every 10 seconds
@crython.job(second=range(0,60,10))

which is true and good behaviour. However from that I expected the same use for minutes:

# fire every 10 minutes
@crython.job(minute=range(0,60,10))

But as second= defaults to '*', we actually get:

# fire every second of every 10th minute
@crython.job(minute=range(0,60,10))

Is this intended?

@MrMathias MrMathias changed the title using minute= assumes second='*' using minute= only assumes second='*' Oct 17, 2018
@ahawker
Copy link
Owner

ahawker commented Oct 18, 2018

@MrMathias

Thanks for the good question. I do agree that this has somewhat of a high astonishment factor.

The work-around is .job(second=0, minute=range(0, 60, 10)) but definitely a valid question if wildcard should be the default.

I don't believe cron proper has any prior art/guidance in this case as it requires you to specify the entire expression and can't do partials.

Least astonishment would be that if you specify a single field, all lesser fields get defaulted to zero in that case. However, I'm not sure I like that either because you're specifying an individual field, not an expression. If the keyword arg was named minutely? instead of minute (hourly vs. hour) I'd feel stronger about changing it.

Anyways, lots of thoughts/rambling. Thanks for the question, it's got the gears churning. I'll think more about it. For now, I'd just stick to the work-around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants