[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exposing subsecond precision in current-seconds

From: Peter Bex
Subject: Re: Exposing subsecond precision in current-seconds
Date: Wed, 29 Apr 2020 18:55:40 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

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


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]