Re: encode-time vs decode-time

[Paul Eggert]

On 7/30/19 12:54 PM, I wrote:
> 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.

Come to think of it, we would also need to change this obsolescent API 
for encode-time:

> As an obsolescent calling convention, if this function is called with
> 6 or more arguments, the first 6 arguments are SECOND, MINUTE, HOUR,
> DAY, MONTH, and YEAR, and specify the components of a decoded time,
> where DST assumed to be -1 and FORM is omitted.  If there are more
> than 6 arguments the *last* argument is used as ZONE and any other
> extra arguments are ignored, so that (apply #'encode-time
> (decode-time ...)) works; otherwise ZONE is assumed to be nil.

Several places in the code use this obsolete API and do (apply 
#'encode-time FOO) where FOO is either the munged result of an earlier 
decode-time or is created from scratch. So, if we made the change as 
described above, we'd also need to change the obsolescent API to be 
something like this:

"As an obsolescent calling convention, if this function is called with 6 
or more arguments, the first 6 arguments are SECOND, MINUTE, HOUR, DAY, 
MONTH, and YEAR, and specify the components of a decoded time, where DST 
assumed to be -1 and FORM is omitted. If there are between 7 and 9 
arguments the *last* argument is used as ZONE and if there are 10 
arguments the 9th is used as ZONE and the 10th as a fractional-second 
argument (TICKS . HZ) and in either case any other extra arguments are 
ignored, so that (apply #'encode-time (decode-time ...)) works. In this 
obsolete convention, the default  ZONE is nil and the default fractional 
second is zero."

Good thing that API is "obsolescent"....