> On Oct 28, 2022, at 2:25 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> For all use cases, I can think of, SRFI 226 needs only two procedures
> that deal with times:
>
> (time? OBJ)
> Returns #t if OBJ is a time value representing a point in (proper)
> time, #f otherwise.
>
> (nanoseconds-from-now N)
> Returns a time value representing N nanoseconds from the time of
> invoking this procedure.
>
> For convenience, one can add a third procedure:
>
> (seconds-from-now X)
> Returns a time value representing X seconds from the time of invoking
> this procedure.
>
> This very minimal interface should be compatible with any high-level
> or extended API.
>
> Do you like the names "nanoseconds-from-now" and "seconds-from-now",
> or have you thought of better names?
>
> Thanks,
>
> Marc
>

Calculating time relative to now using (XXX-from-now …) is only useful if you need to compute a single time in the future.  It leaves no option for computing precisely two or more times in the future that have a fixed delta.  For example:

  (let* ((t1 (seconds-from-now 10))
         (t2 (seconds-from-now 15)))
    …)

The times t1 and t2 are only approximately 5 seconds apart because execution takes time in an unpredictable way (e.g. process was interrupted or swapped out between the two calls).

It is better to have a way to add some seconds to a given time to get another time, for example (seconds+ <seconds> <time>) -> <time> .  The above would become:

  (let* ((now (current-time))
         (t1 (seconds+ 10 now))
         (t2 (seconds+ 15 now)))
    …)

And for the simple case you have (seconds-from-now 10) = (seconds+ 10 (current-time)) , which is not even that much longer.

As for (nanoseconds-from-now N) I think it is sufficient to just use seconds.  In 20 years nanoseconds might be “old school” and you really want picoseconds, in 50 years femtoseconds, etc.  What is wrong with expressing short times in seconds, the SI unit for time?

Marc