Re: Exposing subsecond precision in current-seconds

[felix . winkelmann]

> Fair enough, but the original question was about having subsecond info
> about the current time.  So if I'm understanding you correctly this
> is something better developed as an egg, outside of core.

That's correct.

> Yeah, like I said in my other message, we could use the name
> current-process-milliseconds, like Racket;
> https://docs.racket-lang.org/reference/time.html
>
> I like the name, because it's pretty clear what it does; it yields the
> number of milliseconds the process has been running for.
>
> We can make it a procedure without arguments, because that part of the
> Racket interface looks messy and confusing to me.

Yes, makes sense.

> > 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.
>
> Yes, I agree that for those use cases you don't want to be consing.
> But then microsecond precision might be too much already, on 32 bit
> platforms.  A program that has an uptime of a month already needs 42
> bits to represent the time since startup in microseconds.

Unfortunately it does. Perhaps we have to put more thought into this.

> I think millisecond precision is enough for core, and I'm not sure we
> need microseconds.  So far, I think the use cases we've discussed aren't
> necessarily those of OP.
>

Probably not, but a SRFI-174 egg would be sufficient in that case, I'd say.


felix