Re: encode-time vs decode-time

[Paul Eggert]

> > So now, as you suggested, encode-time has reverted to its old role 
> > of converting from decoded timestamps to Lisp timestamps and its API is now simpler.
>
> Thanks, but judging by the changes in Lisp files all over, it sounds
> like this is a backward-incompatible change?

It's not as scary as it might first appear. The changes to the lisp/* files that 
work around backward-incompatibility issues (by replacing (encode-time TIME 
FORM) with (time-convert TIME FORM)) are needed only to fix Emacs internals code 
that had already been changed to rely on Emacs 27 encode-time. Since Emacs 26 
does not support (encode TIME FORM), users will not have to worry about making 
these kinds of changes to their own code.

They only significant backward-compatibility issue I see is in the 2nd patch 
("decode-time now returns subsec too"), which affects any user code that 
requires (= 9 (length (decode-time))). I originally proposed extending 
decode-time's API with a FORM option 
<https://lists.gnu.org/r/emacs-devel/2019-07/msg00750.html> that would cause 
decode-time to continue to behave as before unlless the given the new FORM 
argument; this would default to current behavior and so would avoid the 
backward-compatibility issue. However, Lars inspected uses of decode-time 
<https://lists.gnu.org/r/emacs-devel/2019-07/msg00772.html> and found that they 
invariably did something like (nth N (decode-time...)) or (apply #'encode-time 0 
0 0 (nthcdr 3 (decode-time))). These uses will continue to work, so Lars 
convinced me that his proposal to return a 10-element list was better. If you 
prefer the more-backward-compatible approach I could look into redoing the time 
code that way, though I expect it'll be a bit more hassle to document it and to 
support it internally.