3 ms·

I just tried it for the first time and immediately noticed a bug. 5 4 1 9 * works fine for signifying the first day in September, 5 4 30 9 * signifies the last

I just tried it for the first time and immediately noticed a bug. 5 4 1 9 * works fine for signifying the first day in September, 5 4 30 9 * signifies the last day in September, 5 4 0 9 * fails because months never have a zeroth day, 5 4 32 9 * fails because months never have a 32nd day... but (here's the problem) 5 4 31 9 * is accepted as valid. This is wrong because September never has 31 days. A little experimentation confirms that 31 is accepted as a valid input for all the months, while 32 is appropriately always rejected. This bug is easy to fix, as the correct length of months is easy to determine. While fixing this, bonus points for warning users when they've scheduled a job either within the span where the time will be hit twice when the clocks roll back for Daylight Savings Time, or within the span where a job will never run on the night when the clocks are adjusted forward. [0] Also helpful to let users know when they've scheduled a job that will only run during a leap year. [1] [0] https://stackoverflow.com/questions/13195999/daylight-savings-and-cron https://stackoverflow.com/questions/13195999/daylight-saving... [1] https://www.nbcdfw.com/weather/weather-connection/a-leap-year-does-not-happen-every-4-years/2321237/ https://www.nbcdfw.com/weather/weather-connection/a-leap-yea...

encoderer 5y ago
Hey Justin, thanks for taking the time to fuzz the UI a bit. There is definitely improvements we could make. Crontab.guru essentially applies the same validations that Vixie cron does when you save a job. If you use "crontab -e" it will let you add a job with the schedule 5 4 31 9 *, and it flags the others you mentioned as invalid. For the most part, crontab.guru tries to be true to Vixie cron. Also, good news on the daylight savings front. As you can imagine with a service like Cronitor we had to learn a lot about this. In most modern versions of Cron, jobs scheduled with a specific time will not be replayed or skipped when the clock moves for DST. You can see the logic here: https://github.com/svagner/vixie-cron/blob/master/cron.c#L223 https://github.com/svagner/vixie-cron/blob/master/cron.c#L22...
- justin66 5y ago
  > For the most part, crontab.guru tries to be true to Vixie cron. One major reason Vixie cron doesn't warn people that they've created a job which will never run, or will only run in a leap year, or whatever, is that there's no convenient way to issue the warning. The thing is configured prior to runtime via text editor. There's zero downside to anyone if you warn people they've created a job that will never run. It's less important than the end of month warning which is so easy to fix, but the nice part about warning about jobs in the DST window is that the warning helps out everyone, regardless of whether they're using a modern version of Vixie cron. So much job-scheduling related software relies on cron syntax, and I'd venture to guess a lot of those people would be happy to use your tool, probably more than the traditional Unix administrators. Granted, it's a weird warning to word properly.

encoderer 5y ago

Hey Justin, thanks for taking the time to fuzz the UI a bit. There is definitely improvements we could make. Crontab.guru essentially applies the same validations that Vixie cron does when you save a job. If you use "crontab -e" it will let you add a job with the schedule 5 4 31 9 *, and it flags the others you mentioned as invalid. For the most part, crontab.guru tries to be true to Vixie cron. Also, good news on the daylight savings front. As you can imagine with a service like Cronitor we had to learn a lot about this. In most modern versions of Cron, jobs scheduled with a specific time will not be replayed or skipped when the clock moves for DST. You can see the logic here: https://github.com/svagner/vixie-cron/blob/master/cron.c#L223 https://github.com/svagner/vixie-cron/blob/master/cron.c#L22...

justin66 5y ago
> For the most part, crontab.guru tries to be true to Vixie cron. One major reason Vixie cron doesn't warn people that they've created a job which will never run, or will only run in a leap year, or whatever, is that there's no convenient way to issue the warning. The thing is configured prior to runtime via text editor. There's zero downside to anyone if you warn people they've created a job that will never run. It's less important than the end of month warning which is so easy to fix, but the nice part about warning about jobs in the DST window is that the warning helps out everyone, regardless of whether they're using a modern version of Vixie cron. So much job-scheduling related software relies on cron syntax, and I'd venture to guess a lot of those people would be happy to use your tool, probably more than the traditional Unix administrators. Granted, it's a weird warning to word properly.