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

[Eli Zaretskii <eliz@gnu.org>]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: 32902@debbugs.gnu.org
> Date: Wed, 3 Oct 2018 11:45:12 -0700
> 
> > 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.

Thanks.

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

OK, but can we call the new file something like timefns.c?  systime.c
sounds wrong to me (these isn't system-dependent stuff).