Re: current-time and GMP

[Stefan Monnier]

>> - use GMP's mpf or mpq numbers (that seems like a lot of work for this
>>    only use, tho I guess we could then use those numbers in Calc as
>>    well).
> Since the underlying nominal precision is typically nanoseconds, mpf is
> unsatisfactory since it's inexact,

Indeed, the problem with it is that mpf works with binary rather decimal
exponents so it can't represent exactly the 10^-9 of nanoseconds.

> and mpq's canonicalization would lose useful information about
>  timestamp resolution.

Not sure to what extend knowledge about the resolution is important here.

> Also, as you mention, both approaches are overkill for timestamps.

That's right.

> Furthermore, we extend existing timestamp functions to accept the form (A),
> where A is an integer, to stand for a timestamp with count A using
> clock-resolution ticks per second since the epoch.

I guess in practice it might work fine, but I'm uncomfortable with the
idea of using a representation that depends on `clock-resolution`, so if
you print a timestamp with one Emacs and read it with another they may
disagree (in a big way) about what it means (if one Emacs uses
nanoseconds while the other uses picoseconds resolution).

> Finally, let's deprecate the long-obsolete timestamp form (A . B)
> where A and B are integers,

Sounds good.

> so that future Emacs versions can support a new
> format where B is the timestamp resolution.

Right, I think (INTEGER-TIMESTAMP . RESOLUTION) would be a nice
representation.  We can additionally (and temporarily) signal an
error/warning if INTEGER-TIMESTAMP (and/or RESOLUTION) is "too small"
(indicating a very likely use of the deprecated (HOGH . LOW)
representation).


        Stefan