[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Support for sub-second time in decoded time
From: |
Stefan Monnier |
Subject: |
Re: Support for sub-second time in decoded time |
Date: |
Mon, 29 Jul 2019 10:43:55 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Lars Ingebrigtsen [2019-07-29 16:12:34] wrote:
> Stefan Monnier <address@hidden> writes:
>
>>> `current-time' returns its data as (HIGH LOW USEC PSEC), but now that we
>>> have bignum support, perhaps we don't need to do it this way. What
>>> about just having a field in decoded times that's the fraction of a
>>> second? So 34.5603 seconds would be represented as
>>>
>>> (34 ... 5603)
>>
>> `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
-- Stefan
- 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