[Top][All Lists]

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

Re: encode-time vs decode-time

From: Paul Eggert
Subject: Re: encode-time vs decode-time
Date: Fri, 16 Aug 2019 23:47:12 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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:


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))
      (if (eq MONTH 12)
          `(,SECONDS ,MINUTES ,HOUR ,DAY ,1 ,(1+ 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/>.

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

reply via email to

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