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

[Max Nikulin <manikulin@gmail.com>]

Confirmed

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.