On Wed, Apr 29, 2020 at 06:21:12PM +0200, felix.winkelm...@bevuta.com wrote: > > On Wed, Apr 29, 2020 at 05:36:10PM +0200, felix.winkelm...@bevuta.com 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
