Actually, this only happens with SCHEDULED timestamps, so it might be considered org-mode's fault since the handling of normal and SCHEDULED timestamps is not always consistent.
The reason it is different is that `org-agenda-get-timestamps' looks for timestamps in the org buffer using a regular expression that already matches only the expected date. `org-agenda-get-scheduled' can't do that, so it uses a regular expression that matches any timestamp, converts the timestamp to an absolute date using `org-agenda--timestamp-to-absolute', and compares with the current agenda date. `org-agenda-get-timestamps' also has to do something similar for repeated tasks. However, the function used to get the absolute date is different for those timestamps. The function for scheduled timestamps boils down to (time-to-days (encode-time (org-parse-time-string timestamp))) but for repeating timestamps, it boils down to (calendar-absolute-from-gregorian (org-date-to-gregorian timestamp)) For the timestamp "<2022-03-30 miƩ 23:00>", the second form returns 738244 in my machine, which corresponds to (org-today) at 30/03/2022, but the second returns 738245. Thus, repeated timestamps still work, but scheduled timestamps don't. Is there a reason why two different ways to obtain those dates are used? For completion, I have also checked deadline timestamps, and they suffer from the same problem as scheduled timestamps. A deadline for today at 23:00 will appear in the agenda as it would a deadline for tomorrow at 22:59, that is, with a warning that it is due in one day, and not as a deadline for today at 22:59 would appear. Regards, Ignacio Ignacio Casso <ignacioca...@hotmail.com> writes: > Hello, > > After last Saturday's hour change in Spain, org-agenda thinks that > timestamps after 23:00 correspond to the next day in Emacs 29. I'm not > actually sure if that is the reason, since I usually use Emacs 27, but I > guess it must be that if I have found out three days after the hour > change. > > I have tried to track down the problem, and it doesn't seem to be the > fault of any org-mode code change. The problem is that > (org-time-string-to-time timestamp), defined as (encode-time > (org-parse-time-string timestamp)), returns different things in Emacs 27 > and Emacs 29. > > Let's consider the timestamp "<2022-03-29 mar 23:00>" as an example: > > 1) (org-parse-time-string "<2022-03-29 mar 23:00>") returns (0 0 23 29 3 > 2022 nil nil nil). > > 2) (encode-time '(0 0 23 29 3 2022 nil nil nil)) returns '(25155 29520) > in Emacs 27, but (25155 33120) in Emacs 29 > > 3.1) (time-to-days '(25155 29520)) returns 738243 > > 3.2) (time-to-days '(25155 33120)) returns 738244 > > 4) (org-today) returns 738243 > > Therefore, org-agenda thinks that "<2022-03-29 mar 23:00>" is today in > Emacs 27, but tomorrow in Emacs 29. > > `encode-time' is defined in C, and is probably system dependent, so this > is probably not an org-mode bug. But maybe org-mode code could try to be > smart about this? I don't know if it's even possible. > > And if this should not be fixed in org-mode, do you know were it should? > It could be an Emacs bug? Or maybe the problem is in my system? > > Regards, > > --Ignacio > > > Emacs : GNU Emacs 29.0.50 (build 19, x86_64-pc-linux-gnu, GTK+ Version > 3.24.20, cairo version 1.16.0) > of 2022-03-29 > Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ > /home/ignacio/repos/emacs/lisp/org/)