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 <[email protected]>: > > Am Fr., 28. Okt. 2022 um 20:59 Uhr schrieb Marc Feeley > <[email protected]>: > > > > > > > On Oct 28, 2022, at 2:25 PM, Marc Nieper-Wißkirchen > > > <[email protected]> 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.
