4 ms·
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 validati
by 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.