Adding a Last Day of Month Schedule Feature

[nameoftherose]

Good Morning,
I would like to add a Last Day of Month Schedule, that would run jobs at a certain ttime at the last day of month, regrdless number of month days.
I would like your advice. Would you suggest adding a special symbol for the dayOfMonth field (An L perhaps, or interpreteng 31 as last day when month field is *) or create a new directive @endofmonth?
What function / files will need modification?
I do not ask you to implement this, just ask your advice.
I know that the end of month logic could be part of the command but i do not want to follow this route.
Thank You.

[yo8192]

Hi,

It would be good to keep the syntax consistent with other systems. From a quick search I didn't see any other Linux cron offering this. But I see some other systems which use cron-like syntax use the "L" you suggested: the java Quartz Scheduler and AWS EventBridge Scheduler has the "L". I imagine that's why you suggested this, and it sounds good to me. Adding a Vixie-cron-style shortcut "@endmonthly" would also work from a user syntax point of view. If doing the more general "L" solution proved too complicated, you could fall back on a "@endmonthly" only (but there is still the question of how you'd store that and implement the logic under the hood).

Note it may be a bit of work to add cleanly though, because it would break the assumption that the "days of the month" field is effectively a bool array with each day enabled/true or disabled/false.
A few pointers in the code:

• The data structure is in cl.h --> cl_t, and an array of bits is used to store this.
• Parsing the cron line string is in fileconf.c --> read_arys().
• The scheduling (when the job should run next) is in database.c --> set_next_exe()

Note that more recently we have added some unit tests in the tests/ folder. While it is retrofitted and in some ways a bit clunky (e.g. we import loads of things to test anything), we should definitely expand those. So I would expect you add tests for anything you want to change before you change anything, to have a better chance of spotting any regression/bug you might introduce by mistake.

In particular:

• extend the existing tests/parse_job_test.c
• add tests on the scheduling (set_next_exe()). That's obviously an important one we'd need to cover well.