[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: current-time and GMP

From: Paul Eggert
Subject: Re: current-time and GMP
Date: Wed, 29 Aug 2018 02:07:17 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Stefan Monnier wrote:

- keep it as is (that's the easy way out)

It really should be fixed. Suggestion below.

- 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

Since the underlying nominal precision is typically nanoseconds, mpf is unsatisfactory since it's inexact, and mpq's canonicalization would lose useful information about timestamp resolution. Also, as you mention, both approaches are overkill for timestamps.

- use a handmade arbitrary-precision float made up of a bignum plus
   a "scaling factor" (halfway solution: less work, but less gain).

Here's a variant of that idea: add a function that yields the current time as an integer count, and a constant that yields the system timestamp resolution. So, for example, if (current-time) yields (23430 22558 300289 683000), representing 2018-08-29 08:23:58.300289683 UTC (i.e., 1535531038.300289683 seconds after the Epoch), we add a function (current-clock) yielding 1535531038300289683 and a constant clock-resolution yielding 1000000000. (As luck would have it, these are both fixnums on 64-bit hosts.)

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. Thus, for example, the following two calls would be equivalent:

(format-time-string "%Y-%m-%d %H:%M:%S.%N" '(1535531038300289683) t)
(format-time-string "%Y-%m-%d %H:%M:%S.%N" '(23430 22558 300289 683000) t)

and would both yield "2018-08-29 08:23:58.300289683". This would be an upward-compatible extension to current behavior for these functions.

Finally, let's deprecate the long-obsolete timestamp form (A . B) where A and B are integers, so that future Emacs versions can support a new format where B is the timestamp resolution. By "deprecate" I mean Emacs issues a runtime warning if the obsolete form is used. As the old timestamp form has obsolete for two decades and has been documented to be obsolete for over a dozen years, it's OK to deprecate it now.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]