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
> attention.

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.