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

node-cron's month does not follow normal cron spec #475

Closed
mogzol opened this issue Feb 28, 2020 · 4 comments · Fixed by #667
Closed

node-cron's month does not follow normal cron spec #475

mogzol opened this issue Feb 28, 2020 · 4 comments · Fixed by #667
Labels

Comments

@mogzol
Copy link

mogzol commented Feb 28, 2020

node-cron's month is 0-based, while cron months are regularly 1-based. See the cron manpage: http://man7.org/linux/man-pages/man5/crontab.5.html:

field          allowed values
-----          --------------
minute         0-59
hour           0-23
day of month   1-31
month          1-12 (or names, see below)
day of week    0-7 (0 or 7 is Sunday, or use names)

So specifying a month of 4 should be April, but with node-cron, it is May: https://stackblitz.com/edit/js-7fmtr2

I don't see why node-cron would use 0-based values for the month. It is confusing for users used to other cron tools, especially when the readme recommends tools such as crontab.guru, which will tell users the wrong month: https://crontab.guru/#0_0_1_4_*

The only place in the readme that mentions this is the section that outlines cron ranges, and it fails to point out that this deviates from normal cron behaviour. It should be made more clear that node-cron's months are non-standard, or node-cron should be updated to match regular cron behaviour (though that would cause a BC break).

@jftanner
Copy link

I just discovered this as well when a job failed to run on the day expected.

This should definitely be clearly called out in the docs, since we used Crontab as linked from the documentation to verify our settings.

@intcreator
Copy link
Collaborator

intcreator commented Feb 23, 2023

this is correct but changing this behavior would be a breaking change so it would have to wait for 3.0 if implemented. feel free to make an MR

@sheerlox
Copy link
Collaborator

This is being worked on in #667 and will get released under v3 🎉

@ncb000gt
Copy link
Member

🎉 This issue has been resolved in version 3.0.0-beta.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

Successfully merging a pull request may close this issue.

5 participants