bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 29 Apr 2022 12:38:19 -0700
> Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 4/29/22 04:10, Eli Zaretskii wrote:
> > Then why again would we want to come up with new functions for
> > handling timestamps? just because the existing ones have names that
> > make discovery difficult, or are there other reasons?
> 
> I think Lars is saying both, though the other reasons are more important.
> 
> Lars makes a good point that common idioms like 
> (file-attribute-modification-time (file-attributes F)) generate 
> unnecessary garbage. And it's more than just GC overhead: at a lower 
> level, 'statx' on GNU/Linux can be significantly more efficient than 
> plain 'stat' when retrieving just a subset of stat info (such as, just 
> the file timestamp).

This is (almost) unrelated to timestamps.  The same case can be made
about almost every individual file attribute, at least theoretically.

But before we implement a separate primitive for each attribute, we
should ask ourselves: what are the use cases where a Lisp program
would want to use such a primitive.  Taking the file's modification
time as an example, are there any important use cases except
determining if a file is older or newer than another?  Because we
already have a primitive for that.