Re: encode-time vs decode-time

[Andy Moreton]

On Tue 30 Jul 2019, Lars Ingebrigtsen wrote:

> Stefan Monnier <address@hidden> writes:
>
>> I think we should clarify:
>>
>> - "time string", as returned by format-time-string and accepted
>>   by parse-time-string.
>>
>> - "decoded time", i.e. a list of the form (SECOND MINUTE HOUR DAY MONTH YEAR 
>> IGNORED DST ZONE)
>>   I just pushed a patch which defines the `decoded-time` *type*, so we can
>>   refer to that precise name in docstrings.
>
> Makes sense.
>
>> - "time counted in seconds" for which we support several representations:
>>   a plain number, a list of integers (HIGH LOW USEC PSEC), a pair of
>>   integers (NUMERATOR . DENOMINATOR).
>>
>> And part of the confusion for me is that `encode-time` not only encodes
>> time, but can also be used to convert between different representations
>> of "time counted in seconds" (in which case it's not the inverse of
>> decode-time).
>
> Yes, that's something that I think was added by Paul late last year, and
> which I think was a mistake, because it makes things conceptually
> confusing.
>
> I think the stuff to convert between the various "time counted in
> seconds" stuff should be a separate function, because it has nothing to
> do with "decoded time".

It seems that the naming of these functions is unhelpful. They should
clearly distinguish between timestamps (absolute time/date) and
durations (relative intervals) and be named as such.

    AndyM