Please see "5.12 Time Objects" in my personal draft:
https://htmlpreview.github.io/?https://github.com/mnieper/srfi-226/blob/master/srfi-226.html.

@Marc: Thanks for helping me to get my interface right and for the
"seconds+"  naming suggestion.

Am Fr., 28. Okt. 2022 um 21:15 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
>
> Am Fr., 28. Okt. 2022 um 20:59 Uhr schrieb Marc Feeley
> <xxxxxx@iro.umontreal.ca>:
> >
> >
> > > 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).
>
> That's a very good point.
>
> > 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.
>
> I have to think about the name, but yes, this is what need.  And it is
> shorter than SRFI 18's
>
> (seconds->time (+ 10 (time->seconds (current-time))))
>
> (I know that SRFI 18 allows "raw" real numbers as time differences
> from the current time (when used as timeouts) and this is what is
> still in draft #2 of SRFI 226. But I would like to make the interface
> "type-safer" in anticipation of future time APIs.)
>
> > 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?
>
> I would be fine with just seconds; others have voiced the wish for
> nanoseconds, including John.
>
> But we can leave nanoseconds out for SRFI 226; future time APIs can
> add such procedures.