[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Support for sub-second time in decoded time
From: |
Lars Ingebrigtsen |
Subject: |
Re: Support for sub-second time in decoded time |
Date: |
Mon, 29 Jul 2019 17:00:31 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
>>> `encode-time` uses a fraction-representation (NOM . DENOM), which is
>>> probably easier to manipulate.
>>
>> You mean internally?
>
> No, as yet-another format.
>
>> It doesn't seem to be mentioned in the doc string,
>> but it's an entire essay now...
>
> It's here:
>
> If FORM is a positive integer, the time is returned as a pair of
> integers (TICKS . FORM), where TICKS is the number of clock ticks and FORM
> is the clock frequency in ticks per second. (Currently the positive
> integer should be at least 65536 if the returned value is expected to
> be given to standard functions expecting Lisp timestamps.) If FORM is
> t, the time is returned as (TICKS . PHZ), where PHZ is a platform
> dependent
> clock frequency in ticks per second. If FORM is ‘integer’, the time is
Hm, OK. But I don't see how that relates to adding a new sub-second
field to the output value from `decode-time'. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
- Support for sub-second time in decoded time, Lars Ingebrigtsen, 2019/07/29
- encode-time vs decode-time, Stefan Monnier, 2019/07/29
- Re: encode-time vs decode-time, Lars Ingebrigtsen, 2019/07/30
- Re: encode-time vs decode-time, Andy Moreton, 2019/07/30
- Re: encode-time vs decode-time, Lars Ingebrigtsen, 2019/07/30
- Re: encode-time vs decode-time, Paul Eggert, 2019/07/30
- Re: encode-time vs decode-time, Paul Eggert, 2019/07/30
- Re: encode-time vs decode-time, Lars Ingebrigtsen, 2019/07/31
- Re: encode-time vs decode-time, Stefan Monnier, 2019/07/31