Re: Exposing subsecond precision in current-seconds

[Peter Bex]

On Wed, Apr 29, 2020 at 06:21:12PM +0200, address@hidden wrote:
> > On Wed, Apr 29, 2020 at 05:36:10PM +0200, address@hidden wrote:
> > > Microseconds since epoch? Are you sure about this?
> >
> > What else would the new current-microseconds return?
> 
> Since startup, or since some undefined point of time. I see no sense in using
> an absolute basetime, as such a timing command will in nearly all use cases
> be used for relative timing.

At work I deal a lot with timestamps, and while mostly you don't need
sub-second precision, when you do, it's nice to be able to represent a
timestamp with millisecond-precision using the standard method of time
representation, and be able to use the standard procedures for
calculations and conversions back and forth.

Anything else is just extra hassle and yak shaving, IMO.

It doesn't matter if it's epoch or some other arbitrary point in time,
of course.  So, we could reduce the range by picking, let's say the
date of the original CHICKEN announcement, or something.

> One should also attempt to reduce the range to
> avoid bignum allocation, I think.

I think it's fine.  (integer-length (* (current-seconds) 1000000)) => 51,
so with 64 bits we can last quite a while.  Whether you're allocating a
double or a 64-bit bignum does not make much of a difference in memory
usage.

Cheers,
Peter

signature.asc
Description: PGP signature