I thought of that, but the use of "seconds" might suggest "current-second", which is a non-Posix count that includes leap seconds and is based on a specific epoch.  Given these things, you can construct a comparator if you need one, using timespec?, timespec=?, timespec<?, and timespec->inexact and then hashing the resulting float.  I guess adding timespec-hash wouldn't hurt; in the sample implementation for 128, floats are hashed with inexact->exact and abs.


On Wed, Nov 13, 2019 at 12:34 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
> I agree that it's too big a dependency and probably shouldn't be there.

I'm neutral on that.

> adding timespec=, timespec<, and friends

Since several Schemes will hopefully have a fast opaque timespec type,
these would be a good idea.

> timespec->inexact and for completeness inexact->timespec

Would these convert between timespecs and floats (where the integer part
is seconds relative to the epoch)? May be a good idea.

As discussed on the SRFI 170 mailing list, Gambit has an opaque time
type as well as `time->seconds` and `seconds->time` procedures for
converting to/from ordinary floats. So it would be easy to convert a
timespec into a time object with (seconds->time (timespec->inexact ts))
and vice versa. Of course, Gambit could provide faster `timespec->time`
and `time->timespec` procedures as well.

Maybe `timespec->seconds` and `seconds->timespec` would be more obvious
names for the SRFI?