Mmm, I'm not that happy with full arithmetic. I defined (- timespec1 timespec2) to return a timespec, but given the definition as the number of seconds/nanoseconds since an epoch, a difference is really a duration rather that another timespec. The eventual time SRFI will have durations, so let's leave that out for now. And adding a timespec to a duration makes sense, but adding a timespec to a timespec does not. As for multiplying, I can see multiplying a duration by a number, but not {duration,timespec} * {duration,timespec}.

I think we need a small SRFI as I discussed before, with the following bindings:

(make-timespec seconds nanos epoch) ; epoch is an identifier bound to an integer

(timespec-seconds timespec)

(timespec-nanos timespec)

(timespec_epoch timespec)

(timespec->seconds ; as in current-second, will need UTC to TAI conversion*

(seconds->timespec seconds) ;sets CLOCK_REALTIME epoch, needs TAI to UTC conversion*

(timespec-comparator)

Timespec->iso and iso->timespec would also be very useful, and easy to do (not a full iso 8601 parser, just the simple case in the UTC time zone needed here.) Easy-peasy.

Comments?

*There are different ways to do the TAI conversion. You can use ntp_adjtime as Chibi does, but it can also be done statically by fetching <http://maia.usno.navy.mil/ser7/tai-utc.dat> at build time. See the Implementation Notes section of <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/TimeAdvancedCowan.md> for details. Unfortunately I have not yet written `update-leapsec`.

John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org
Monday we watch-a Firefly's house, but he no come out. He wasn't home.
Tuesday we go to the ball game, but he fool us. He no show up. Wednesday he
go to the ball game, and we fool him. We no show up. Thursday was a
double-header. Nobody show up. Friday it rained all day. There was no ball
game, so we stayed home and we listened to it on-a the radio. --Chicolini