Re: Support for sub-second time in decoded time

[Paul Eggert <eggert@cs.ucla.edu>]

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. 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