[Top][All Lists]

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

bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps

From: Paul Eggert
Subject: bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps
Date: Wed, 3 Oct 2018 11:45:12 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 10/1/18 8:04 PM, Eli Zaretskii wrote:

Doc strings only send to
the manuals for additional details and explanations, not for the basic
facts such as these.

The attached proposed additional patch fixes this by referring to format-time-string, and by adding the description of time values to format-time-string's doc string. (This is better than the old practice of referring to current-time-string, which does not deal with subsecond info.) It also fixes some minor doc nits I noticed in additional reading.

This makes an impression the function doesn't support more than 2
arguments, which is incorrect.  Can we provide a more accurate 'usage' form?

Yes, and I gave that a shot in the attached patch.

I think it would be good to add tests for the functions being
modified, otherwise we might be breaking something without paying

Good point, and done in the attached.

Is it feasible to leave the time-related code in editfns.c?

It's feasible, and I could prepare a patch along those lines. However, the time code has has nothing to do with edit functions and is growing significantly: the proposed src/systime.c is 56 KiB, which is above the median size for src/*.c files. Also, this patch changes the time code so much that moving it to a new file won't be that much more of a forensics annoyance than leaving it in editfns.c. To my mind the clarity in having the time code in its own module outweighs the forensics annoyance.

Attachment: 0001-Improvements-on-TICKS-.-HZ.patch
Description: Text Data

reply via email to

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