Re: encode-time vs decode-time

[Paul Eggert]

> > 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.
>
> Actually, while I agree that it's possible it will break something
> somewhere, it's rather unlikely.

Although I initially thought the same way (that's why I installed the patch that 
altered decode-time), I may have been a bit hasty. I searched for "decode-time" 
in all public GitHub source code files with an .el extension, and looked just in 
the first page of results (10 hits) and found one hit that would have a problem:

https://github.com/tjim/nevermore/blob/5a3f29174b3a4b2b2e7a700a862f3b16a942687e/nm-dateparse.el

It contains several instances of code like this:

(defun nm-next-month (&optional dtime)
  "One month from now, or specified dtime"
  (pcase (or dtime (decode-time))
    (`(,SECONDS ,MINUTES ,HOUR ,DAY ,MONTH ,YEAR ,DOW ,DST ,ZONE)
     (nm-noon
      (if (eq MONTH 12)
          `(,SECONDS ,MINUTES ,HOUR ,DAY ,1 ,(1+ YEAR) ,DOW ,DST ,ZONE)
        `(,SECONDS ,MINUTES ,HOUR ,DAY ,(1+ MONTH) ,YEAR ,DOW ,DST ,ZONE))))))

which won't work if decode-time returns a 10-element list.

Although not a systematic study, this example suggests that we might want to be 
cautious about changing decode-time to return a 10-element list.

With that in mind, I installed the attached patch, which causes decode-time to 
behave at it does in Emacs 26 unless you pass it a new optional argument. And 
even with the new argument, it still returns a 9-element list so the above code 
will still work.

Eli Zaretskii wrote:

> Another alternative is to make the SECONDS member be a float, then we
> could return the extra precision there.

Floats suffer from rounding confusion, and won't suffice for 
attosecond-precision timestamps - admittedly not something one runs into every 
day, but they are needed for some physics applications. The experience that I've 
had with floating-point timestamps over the years has been negative, for the 
usual reasons. So the patch I installed uses the (TICKS . HZ) form that can 
handle attoseconds - indeed, it can even handle zeptoseconds, which were first 
needed by experimental physicists in 2016, according to Jason Daley 
<https://www.smithsonianmag.com/smart-news/physicists-record-smallest-slice-time-yet-180961085/>.

0001-More-compatible-subsecond-calendrical-timestamps.patch
Description: Text Data