On 18/01/2023 16:54, Ihor Radchenko wrote:
Max Nikulin writes:
(dt '(-90 -60 -31 -30 -29 -15 0 15 29 30 31 60 90))
This is problematic. You are putting MINUTES out of normal range.
Actually after some experiments and surprising results I figured out
what really happens. I modified your example to get the value that you
was likely expecting:
(let* ((tz "Europe/Berlin")
(t1 (encode-time `(0 1 3 29 10 2023 nil -1 ,tz)))
;; !!! Try to comment out the line below
(_ (encode-time `(0 59 1 29 10 2023 nil -1 ,tz)))
(t2 (encode-time `(0 59 2 29 10 2023 nil -1 ,tz))))
(list
(format-time-string "%F %T %z %Z" t1 tz)
(format-time-string "%F %T %z %Z" t2 tz)
(time-subtract t1 t2)))
("2023-10-29 03:01:00 +0100 CET" "2023-10-29 02:59:00 +0200 CEST" 3720)
No negative minutes were involved.
I decided that hysteresis example is more funny.
Frankly speaking, I just forgot that I may use (make-decoded-time
:minute -40) and `decoded-time-add' since I was not limited by Emacs-26
support.
`encode-time' docstring for Emacs-26 has the following statement:
Out-of-range values for SECOND, MINUTE, HOUR, DAY, or MONTH are allowed;
for example, a DAY of 0 means the day preceding the given month.
So I do not think it affects anything. I decided to ask GNU libc developers
https://inbox.sourceware.org/libc-alpha/tq93sc$p3$1...@ciao.gmane.io/T/#u
"mktime result may depend on previous calls"
Looking at
https://codecogs.com/library/computing/c/time.h/ctime.php?alias=mktime,
out-of-range minutes are not documented.
Looks like a compilation of unspecified sources. The following is
similar to ctime(3) man page
if structure members are outside their valid
interval, they will be normalized (so that, for example,
40 October is changed into 9 November);
My reading is that out of range values for other "members" are allowed
as well. However it may be tricky.
Also, see
https://stackoverflow.com/questions/20104531/weird-mktime-logic-with-negative-seconds
My expectation is that ±1 day (or month) should preserve local time
hours (e.g. 11:00 CET -> 11:00 CEST) if such moment of time exists. ±24
hours, ±24*60 minutes, ±24*3600 seconds across DST change should cause
appropriate shift of hours (e.g. 11:00 -> 12:00 is possible).
Moreover "out of range" month day 0 is the only way to specify last
month day to get
Jan, 31 <- 1 month -> Feb, 28 (or 29) <- 1 month -> Mar, 31
arithmetic.
However it is hardly implementation specific and GNU date(1) CLI
utility, PostgreSQL, PHP timelib, JavaScript Date objects behave
differently.
I still do not think it affects my example though.
