> > Ubuntu-20.04 LTS has emacs-26.3, so... > > Could you, please, try > > (encode-time '(0 0 23 29 3 2022 nil -1 nil)) > ^^^
Thanks. Using -1 as DST argument indeed fixes it. However, while testing that, I've realized that I made a mistake in the bug report. `encode-time' and `org-parse-time-string' return the same both in old and current Emacs and org-mode versions (by old Emacs I mean Emacs 27, not 26). The problem is that in ELPA's org-mode, `org-time-string-to-time' is defined as (apply #'encode-time (org-parse-time-string s))) and in org-mode's built-in version of Emacs 29, it is defined as (encode-time (org-parse-time-string s))) and those two return different things. In the second case, the actual three last elements of the list returned by `org-parse-time-string' are used, and they are all nil. In the first case, according to the docstring of `encode-time', the last two elements of the list are ignored and -1 and nil are used as default. > If my guess is right, `org-parse-time-string' should add -1 instead of > nil in that position. So your guess is right, and doing this would restore the previous behavior. However, the curious things is that in the org-mode repository at git://git.savannah.gnu.org/emacs/org-mode.git, `org-time-string-to-time' still uses `apply', and always has. The change, and thus the bug, was only introduced directly in Emacs 29 a few months ago. So I guess this is an Emacs 29 bug? I didn't know the two repositories could diverge like that. Should I report it to Emacs 29 maintainers? Or can org-mode maintainers fix it in the Emacs repository?
