[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exposing subsecond precision in current-seconds
From: |
Evan Hanson |
Subject: |
Re: Exposing subsecond precision in current-seconds |
Date: |
Wed, 29 Apr 2020 18:38:54 +1200 |
On 2020-04-27 21:26, address@hidden wrote:
> > - Add a new procedure in `(chicken time)` or `(chicken time posix)` that
> > gives
> > you both seconds and nanoseconds, be it as values, list, vector, ... Same
> > Windows considerations as previously apply.
>
> Probably the best solution, I guess something based on "clock_gettime"
> is the most precise and portable method, even though it may need librt on
> some platforms.
This seems best to me as well.
I think giving the user an exact integer is always nicest, compared to
returning a vector or somesuch. So, something like `current-microseconds`
would be nice, or following the Gambit API that Lassi has mentioned.
We already have `time->seconds' and friends in srfi-18, but it's built
on top of `current-milliseconds'. They could perhaps be updated to use a
`current-microseconds' procedure instead, if we had one, but that might
not be necessary (it certainly isn't necessary from a compliance point
of view, but "real" time values would be more useful).
Cheers,
Evan
- Exposing subsecond precision in current-seconds, Vasilij Schneidermann, 2020/04/27
- Re: Exposing subsecond precision in current-seconds, Lassi Kortela, 2020/04/27
- Re: Exposing subsecond precision in current-seconds, Vasilij Schneidermann, 2020/04/27
- Re: Exposing subsecond precision in current-seconds, felix . winkelmann, 2020/04/27
- Re: Exposing subsecond precision in current-seconds, felix . winkelmann, 2020/04/29
- Re: Exposing subsecond precision in current-seconds, Peter Bex, 2020/04/29
- Re: Exposing subsecond precision in current-seconds, felix . winkelmann, 2020/04/29
- Re: Exposing subsecond precision in current-seconds, Lassi Kortela, 2020/04/29
- Re: Exposing subsecond precision in current-seconds, Peter Bex, 2020/04/29