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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 30 Apr 2022 14:03:55 -0700
> Cc: 55163@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
>  Vincenzo Pupillo <v.pupillo@gmail.com>,
>  Stefan Monnier <monnier@IRO.UMontreal.CA>
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 4/30/22 02:15, Lars Ingebrigtsen wrote:
> >> * (clock-realtime) returns the system-wide clock. It acts like
> >>    (time-convert nil t), i.e., like (current-time) but returning (TICKS
> >>    . HZ) form.
> > clock- as a prefix does make a lot of sense, but I think I'd interpret
> > that as "realtime" as something having to do with scheduling
> 
> Yes, "realtime" is an unfortunate phrase here, even if it's POSIX. 
> Perhaps we should use "universal" instead, since it's Universal Time.

Using "universal" will IMO make the discovery even more difficult,
because no one will think of looking up time functions under
"universal".

> Another thought is that instead of a new Lisp function, we could extend 
> current-time. E.g., (current-time 'universal) would return the current 
> time in seconds since the EPOCH, (current-time 'process-cpu) the 
> process's CPU time, (current-time 'monotonic) a monotonic clock, etc. 
> Although this wouldn't let us reorganize the time API in a major way, it 
> would let us add the needed functionality in a way that follows existing 
> practice pretty closely, and there's benefit to that.

That could be a good idea, but thinking about names, I still don't
understand why we don't want to use "time-" as the prefix of these
APIs.  What did I miss?