Re: encode-time vs decode-time

[Paul Eggert]

On 7/30/19 6:37 AM, Lars Ingebrigtsen wrote:
> a number of seconds can also be used as a duration, but
> that's a different matter.

The issues are not that independent. Just as a Lisp timestamp like 
1564500522 can be treated as absolute (2019-07-30 15:28:42 UTC) or 
relative (1564500522 seconds duration), a calendrical value like (42 28 
15 30 7 2019 2 nil 0) can also be treated as an absolute time (the same 
absolute time, in this example) or as a relative time (using calendrical 
arithmetic).

> adding an optional parameter to `decode-time' to also make it
> include sub-second time in the decoded time structure it returns (also
> as previously discussed) may be the right thing to do.  However, I've
> grepped through the sources now for usages of decoded time, and it kinda
> looks to me like adding a ninth slot in decoded time structures would
> probably not break anything.
Any ninth slot should be a numerator-denominator pair if it's nonzero, 
to avoid losing precision. Something like this:

(decode-time '(1564504076643563153 . 1000000000) t) =>

(56 27 16 30 7 2019 2 nil 0 (643563153 . 1000000000))

> this is very confusing indeed
To some extent the confusion is inherent: there are a lot of useful ways 
to represent and manipulate times, and people unfamiliar with the issues 
will find this complexity confusing. That being said, it would be good 
to simplify the Emacs API for time without significantly hurting 
functionality or compatibility.

So, how about this idea. First we go along the lines of your suggestion, 
and change decode-time to return a ninth slot with a 
numerator-denominator pair that preserves all the precision of its 
argument. Second, we change (encode-time TIME t) so that it also 
preserves all the precision of its argument. This will cause 
(encode-time (decode-time TIME) t) to return a value equivalent to TIME, 
which will simplify roundtripping.