[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: encode-time vs decode-time

From: Eli Zaretskii
Subject: Re: encode-time vs decode-time
Date: Wed, 07 Aug 2019 17:44:47 +0300

> 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]