[Top][All Lists]

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

Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the nex

From: Max Nikulin
Subject: Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Date: Thu, 31 Mar 2022 23:57:55 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0


Emacs copy of Org changed the way of calling `encode-time' as a result interpretation of last nils returned by `org-parse-string' altered from ignored to "no DST".

Kyle, be aware of the conflict with `org-time-string-to-time' when you will port emacs commit dd0727e1ec1f535b9b06be88173b4d3ccd55abcb
Paul Eggert <eggert@cs.ucla.edu> Thu Dec 16 09:40:21 2021 -0800
encode-time simplifications

I hope, it is safe to pad `org-parse-time-string' return value with nil -1 nil instead of nil nil nil, but I have not tried to run tests (if they exist).

New calling convention for `encode-time' exists since emacs-27.1, so it is incompatible with yet supported emacs-26. It is unfortunate that sources in Org and in Emacs repository diverged, but I am unsure if it reasonable to introduce a new compatibility wrapper. Emacs developer may be unhappy if the change will be reverted to way deprecated way to call `encode-time'. For almost a year I am reading messages here that Emacs-28 is about to be released, so Emacs-26 is almost unsupported in Org.

On 31/03/2022 21:11, Ignacio Casso wrote:

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)))

Thank you, Ignacio. I read the code of `encode-time' once more and see that the DST argument is taken into account only when date-time fields are passed as a list. It explains change of behavior despite of absence of apparent recent changes in the code of the function.

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?

The problem is a consequence of grep-refactoring of Emacs code, but likely it should be fixed at the Org side.

reply via email to

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