Re: Exposing subsecond precision in current-seconds

[Peter Bex]

On Wed, Apr 29, 2020 at 06:38:54PM +1200, Evan Hanson wrote:
> On 2020-04-27 21:26, address@hidden wrote:
> > > - Add a new procedure in `(chicken time)` or `(chicken time posix)` that 
> > > gives
> > >   you both seconds and nanoseconds, be it as values, list, vector, ...  
> > > Same
> > >   Windows considerations as previously apply.
> > 
> > Probably the best solution, I guess something based on "clock_gettime"
> > is the most precise and portable method, even though it may need librt on
> > some platforms.
> 
> This seems best to me as well.

Same here.  Less breakage.

> I think giving the user an exact integer is always nicest, compared to
> returning a vector or somesuch. So, something like `current-microseconds`
> would be nice, or following the Gambit API that Lassi has mentioned.

I would prefer current-microseconds.  It's clear what it does and very
similar to the API we already have.  Perhaps a bit weird to have both,
considering one can easily do
(define (current-seconds) (quotient (current-microseconds) #e1e6))

On the other hand, it's kind of rare to need sub-second precision anyway.

The Gambit API seems rather messy to me.  Can't really put my finger on
it, perhaps it's the fact that it uses flonums, but also the fact that
the "time" object seems to be a dumb wrapper for the flonum, there's
no useful abstraction it adds, just an extra barrier to actually get
at the time.

One thing I'm concerned about is that there's current-milliseconds, which
returns the milliseconds since startup, while we'd have current-seconds
and current-microseconds which return the (micro)seconds since the Epoch.

It might be a good idea to deprecate current-milliseconds and rename it.
Perhaps we can use the name current-process-milliseconds, like Racket;
https://docs.racket-lang.org/reference/time.html

> We already have `time->seconds' and friends in srfi-18, but it's built
> on top of `current-milliseconds'.

Yeah, we found out on IRC.  This is of course incorrect, and based on the
confusion in naming I mentioned before.

Cheers,
Peter

signature.asc
Description: PGP signature