Re: Exposing subsecond precision in current-seconds

[felix . winkelmann]

> 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.

I find this unconvincing. These appear to me already as special cases
that would require a customized approach. I see subsecond timing
as a necessarily lightweight internal time-measurement device.

> 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.

I don't disagree here, confusing it is. You suggested deprecating
"current-milliseconds", right? Perhaps it should be replaced by
a differently named primitive.

> > 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.

In that case you have special needs, that's all I'm saying. My goal is
quite clear: I want something simple and efficient, a primitive operation
that is sufficient for cases where efficiency is required, not designed
for what look to me as uncommon cases.

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

Something like "current-microseconds" is likely to be used in time
critical code (schedulers, profilers, etc.) You want to to be fast, ideally
not consing, especially on small or embedded systems.

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

Correct. But it's resolution is too coarse to be a suitable candidate for
tight timing code.


felix