[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: encode-time vs decode-time
From: |
Eli Zaretskii |
Subject: |
Re: encode-time vs decode-time |
Date: |
Tue, 06 Aug 2019 21:23:20 +0300 |
> Cc: address@hidden, address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Tue, 6 Aug 2019 08:59:33 -0700
>
> 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))).
Was this inspection done on Emacs' own code, or also outside Emacs?
- Re: encode-time vs decode-time, Paul Eggert, 2019/08/05
- Re: encode-time vs decode-time, Eli Zaretskii, 2019/08/06
- Re: encode-time vs decode-time, Lars Ingebrigtsen, 2019/08/07
- Re: encode-time vs decode-time, Paul Eggert, 2019/08/17
- Re: encode-time vs decode-time, Eli Zaretskii, 2019/08/17
- Re: encode-time vs decode-time, Paul Eggert, 2019/08/17
- Re: encode-time vs decode-time, Lars Ingebrigtsen, 2019/08/17