php - Time Rescheduling Logic

Solution:

I actually found a pretty easy way to do what I needed, so posting it as an answer.
If we have a value offrequency in seconds (in my case, at least) and we have the originalnextrun, which is when a task was supposed to be run initially, then the logic is as follows:

1. We need to get current time (time(),UTC_TIMESTAMP() or whatever).
2. We need to compare current time againstnextrun and get the difference between them in seconds.
3. We then calculate how many iterations of the task could have been completed in the amount of those seconds by dividing the time difference byfrequency.
4. We round up the resulting value (ceil()). If we have a value lower than 1, we may want to sanitize it.
5. We multiply this rounded up value byfrequency, which will give us a different result than on step 2, which is the salt of this method.
6. We add the resulting number of seconds tonextrun.

And that's it. This does not guarantee, that you won't ever have a task run twice, if it ended just a few seconds before the time value on step 6, but to my knowledge MS Event Scheduler has the same "flaw".
Since I am doing this calculation in SQL, here's how this would look in SQL (at least for MySQL/MariaDB):

UPDATE `cron__schedule` SET `nextrun`=TIMESTAMPADD(SECOND, IF(CEIL(TIMESTAMPDIFF(SECOND, `nextrun`, UTC_TIMESTAMP())/`frequency`) > 0, CEIL(TIMESTAMPDIFF(SECOND, `nextrun`, UTC_TIMESTAMP())/`frequency`), 1)*`frequency`, `nextrun`)
Copy code

To explain by referencing the logic above:

1. UTC_TIMESTAMP()
2. TIMESTAMPDIFF(SECOND, `nextrun`, UTC_TIMESTAMP()) - time comparison in seconds.
3. TIMESTAMPDIFF(...)/`frequency`
4. CEIL(...) to round up the value.IF(...) is used to sanitize, since we can get 0 seconds, that will result in us not changing the time, at all.
5. CEIL(...)*`frequency`
6. TIMESTAMPADD(...)

I do not like having to useTIMESTAMPDIFF(...) twice because ofIF(...), but I do not know a way to avoid that without moving to a stored procedure, which feels like an overkill. Besides, as far as I know, MySQL should calculate this value only once regardless. But, if someone can advise me on a cleaner approach, I'll update the answer.

Solution:

There isn't a right or wrong in this situation, it really depends on your business logic and how you want to build this.

WordPress and Drupal, two of the largest CMSs out there have faced this problem, too, which boils down to "poor man's cron" versus "system cron". For a "poor man's cron", these systems rely on someone hitting the website in order to "wake" the scheduler up, and if no one visits your site in a month, your tasks don't run, either. Both of these systems instead recommend using the system's cron to be more consistent and "wake up" the scheduler at certain intervals. I would encourage you to explore this in your system, too.

The next problem is, how are you storing your recurrence? Do you have (effectively) a table with every possible run time? So for an hourly run there's 24 entries? Or is there just a single task that has an ideal run date/time? The latter is generally easier to control compared to the former which has a lot of duplicated data being stored.

Then, do tasks reschedule themselves, does the scheduler do that, or is there a middle ground where the scheduler asks the task for the next best run? Figuring this out is very important and there's some nuances.

Another thing to think about, what happens if a task runs earlier than planned? For instance, does the world break if a task runs as 01:00 and 01:15, or is it just sub-optimal.

Generally when I build these types of systems, my tasks conform to a pattern (interface in OOP) and support a "next run time". The scheduler pulls all of the tasks from a data store that have an expired "next run time" and runs them. Doing this, there's no chance for a single task to exist at both 01:00 and 02:00 because it will only exist in the data store once, for instance at 01:00. If the scheduler then wakes up at 01:15, it finds the 01:00 task which has expired and runs it, and then it asks the task for the next run. The task looks at the clock (or time as provided by the scheduler if you are running in a distributed environment) and the task performs its own logic to determine that. If the logic is every hour, you can add 60 minutes from "now" and then remove the minutes portions, so 01:15 becomes 02:00.

Throw some exception handling and possibly database transactions into this mix to guarantee that a task can't fail but still get rescheduled, too.