[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: encode-time vs decode-time

From: Paul Eggert
Subject: Re: encode-time vs decode-time
Date: Tue, 6 Aug 2019 08:59:33 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]