Re: Dealing with "past" events

On Sun, 3 Nov 2024 16:53:14 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

Given:
N = "now"
R = task release time
D = task's deadline time
E = event time
>
The only real invariant is that R < N as code executing in a
task can't execute until the task has been released.
>
Specifically, there are no guaranteed relationship between
*most* of these times; N > E, N > D, D < R, etc. are all
possible in a generic system.
>
Though, in a nominal setting, R < N < E < D when the code tries
to initiate an event at a particular (future) time (E).
>
But, what happens when E < N -- i.e., when you try to schedule
an action (event) at a time that has already passed?  And, does
E << N lead to a different interpretation/handling?

There is no general answer to this: the only correct thing to do is
let the user specify how the event is to be treated if its scheduled
time is passed.

It reasonably is safe to assume that a "do it now" event should be
executed as soon as possible, even if was delayed several seconds in
the scheduling.

But beyond that you're speculating.
  

Unix 'cron', 'at', etc. are not particularly good examples to follow -
they are too simplistic.  The set of options available to the Windows
scheduler is better (though not exhaustive), but IMO most of the
"options" should be mandatory parameters that must be provided in
order to schedule an event.

I've argued that the OS shouldn't special-case such activities.
If you request something to happen in the past, then the OS
should just act as if it has *just* happened, regardless as to
whether you were a microsecond "late" in issuing your request
or *years*!  In particular, the OS shouldn't dismiss such request
unilaterally -- or, throw an error to alert the issuer to the
*apparent* inconsistency.

I think it should be an error for a /timed/ (not "now") event to be
scheduled past any possible execution time.  An event that repeats
could be scheduled past its initial run time, but there should be at
least one repetition in the /future/.

E.g., an event that repeats 5 times at 1 day intervals starting 7 days
ago is meaningless now.  But an event that repeats 5 times at 1 day
intervals starting /3/ days ago still has potential to execute.

Arguing that an administrator might (re)set the system time and that
might make a passed event relevant again is just wishful thinking.