[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:
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
- Re: encode-time vs decode-time, Paul Eggert, 2019/08/05
- Re: encode-time vs decode-time, Eli Zaretskii, 2019/08/06
- Re: encode-time vs decode-time, Paul Eggert, 2019/08/06
- Re: encode-time vs decode-time, Eli Zaretskii, 2019/08/06
- Re: encode-time vs decode-time, Paul Eggert, 2019/08/06
- Re: encode-time vs decode-time, Stefan Monnier, 2019/08/06
- Re: encode-time vs decode-time, Eli Zaretskii, 2019/08/07
- Re: encode-time vs decode-time, Lars Ingebrigtsen, 2019/08/11
- Re: encode-time vs decode-time,
Paul Eggert <=
- Re: encode-time vs decode-time, Lars Ingebrigtsen, 2019/08/07
- Re: encode-time vs decode-time, Paul Eggert, 2019/08/17
- Re: encode-time vs decode-time, Eli Zaretskii, 2019/08/17
- Re: encode-time vs decode-time, Paul Eggert, 2019/08/17
- Re: encode-time vs decode-time, Lars Ingebrigtsen, 2019/08/17
- Re: encode-time vs decode-time, Paul Eggert, 2019/08/17
- Re: encode-time vs decode-time, Stefan Monnier, 2019/08/17
- Re: encode-time vs decode-time, Paul Eggert, 2019/08/17
- Re: encode-time vs decode-time, Stefan Monnier, 2019/08/19
- Re: encode-time vs decode-time, Adam Porter, 2019/08/21