[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
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
Re: Support for sub-second time in decoded time, Eli Zaretskii, 2019/07/29
Re: Support for sub-second time in decoded time,
Paul Eggert <=