Exposing subsecond precision in current-seconds

[Vasilij Schneidermann]

Hello,

Today on #chicken I've been reminded that `current-seconds` is unsuitable for
obtaining timestamps with millisecond precision.  Then there is
`current-milliseconds` which returns milliseconds since the process / OS start.
One might be tempted to combine both (as SRFI-19) does, but this is incorrect
as they have different offsets and there will be an unknown error up to a full
second.  Looking at the definition of both, `current-seconds` is using
`gettimeofday` on POSIX platforms which supports up to nanoseconds precision,
then discards it.  I can think of a few possible ways to improve this:

- Change `current-seconds` to use `gettimeofday` in a way that combines both
  seconds and nanoseconds into a double (that should be plenty precision).  On
  Windows a replacement could be defined like with PostgreSQL [1].  Or maybe
  don't bother giving Windows users an enhanced experience and return an
  integer here.
- 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.
- Bonus: Make `current-seconds` return two values, the seconds and nanoseconds.
  Previously written code should continue to function unchanged.  I don't
  really like this idea though, it's a bit too magic and kind of cumbersome
  to use.

Vasilij

signature.asc
Description: PGP signature