Re: encode-time vs decode-time

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Tue, 6 Aug 2019 18:02:30 -0700
> 
> Although almost all uses of decode-time will be unaffected by the change, 
> there's little doubt that some user code somewhere will break because it 
> (mistakenly) assumes that decode-time's result format will never be extended. 
> If 
> this is a real concern, we can go about the change in some other way.
> 
> One alternative would be to leave decode-time's API unchanged from Emacs 26 
> and 
> put the new functionality into a new function, say "time-calendrical". While 
> we're at it, we could call the data structure that the new function returns a 
> "calendrical timestamp" instead of a "decoded timestamp", and rename the 
> recently-added functions make-decoded-time, decoded-time-hour, 
> decoded-time-year 
> etc. to make-calendrical-time, calendrical-hour, calendrical-year, etc. This 
> would reduce confusion, as it is harder to remember what a "decoded time" is 
> than to remember what a "calendrical time" is, at least for me. Also, we 
> could 
> document that the calendrical data structure may change in future versions, 
> and 
> that programs should use the new functions rather than inspect the raw data 
> structure.

Another alternative is to make the SECONDS member be a float, then we
could return the extra precision there.  Would this be a better way to
keep backward compatibility?