Re: Support for sub-second time in decoded time

[Lars Ingebrigtsen <larsi@gnus.org>]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 7/29/19 4:48 AM, Lars Ingebrigtsen wrote:
>> Currently, encoded time has support for picoseconds.  `decode-time' will
>> throw away all sub-second time, which makes accurate round-tripping
>> impossible.
>
> No, it's quite possible.

I meant "round-tripping via the decoded time structure".

> Admittedly it is not that convenient. We could extend decode-time to
> accept an additional argument FORM that would let the caller specify
> the form of the returned value. decode-time could treat FORM much like
> encode-time does, and encode-time would be extended to grok the new
> forms so round-tripping would be simpler. This would be
> upward-compatible with the current behavior.
>
> For example, under this proposal we'd have:
>
> (setq R 1000000000)
> (setq X (encode-time nil R))  =>  (1564418451413082782 . 1000000000)
> (setq Y (decode-time X nil))  =>  ((51413082782 . 1000000000) 40 9 29
> 7 2019 1 t -25200)
> (equal X (encode-time Y R))  =>  t

As I said in a previous message -- this is very confusing indeed, and I
think it should be reworked in a different way before Emacs 27 is
released and it's too late to get rid of this confusion.

But adding an optional parameter to `decode-time' to also make it
include sub-second time in the decoded time structure it returns (also
as previously discussed) may be the right thing to do.  However, I've
grepped through the sources now for usages of decoded time, and it kinda
looks to me like adding a ninth slot in decoded time structures would
probably not break anything.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no