[Top][All Lists]

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

Re: Support for sub-second time in decoded time

From: Paul Eggert
Subject: Re: Support for sub-second time in decoded time
Date: Mon, 29 Jul 2019 11:46:14 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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

No, it's quite possible. Say you want a resolution-R broken-down representation of the Lisp timestamp T. Then you can use (decode-time T) to get the broken-down time in seconds, and (mod (car (encode-time T R)) R) to get the subsecond part. Once you have that, you're off to the races.

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

reply via email to

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