Re: Exposing subsecond precision in current-seconds

[Peter Bex]

On Wed, Apr 29, 2020 at 10:40:06PM +0200, address@hidden wrote:
> > 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[...]
> 
> I'm not sure what you are trying to say here.

I was trying to illustrate how annoying it'd be to have to jump through
hoops if you need to print the time in a human-readable way or convert
it to a more "standard" epoch-based representation that includes
subsecond information.

And also, if current-seconds returns time since the epoch, it's confusing
if current-microseconds or current-milliseconds returns time since
<something else>.  See also the mistake in the SRFI-19 egg where it
appends current-milliseconds to the timestamp, assuming it's using the
same base as current-seconds is.

> But it seems to me that you might need a more abstract representation
> in those cases that you are talking of (which are not as frequent, as
> you say).

In that case, you'd definitely be allocating, which would probably
eat more words than a plain bignum, so I'm kind of confused as to
what your goals are for this API.

> Let's get back to subsecond primitives for the core runtime.

I think of current-microseconds returning a bignum of microseconds
since the UNIX epoch as the simplest thing that could possibly work.

As an alternative, SRFI-174 looks fine to me too, but that would
also imply allocating more than a simple bignum.

I'd like to point out that current-seconds already returns a bignum
on 32-bit systems.

Cheers,
Peter

signature.asc
Description: PGP signature