> Also, I noticed that time is forced to be present even when I do not > enter it, and defaults to current time. It does not feel right. Maybe we > need to put 00:00 or something.
This is just because I set the WITH-TIME argument of org-read-date to t. That's not necessary, org-read-date will accept a time even if with-time is set to nil and when it doesn't receive a time, no time will be added to the parsed time string. Just wanted to add that just in case anyone decides to pick this up in the future. Le ven. 31 juil. 2026 à 11:22, Earl Chase <[email protected]> a écrit : > > Cancelled. > > As I am now employed, I no longer can assign my copyright. > > Le jeu. 30 juil. 2026 à 20:44, Earl Chase <[email protected]> a écrit : > > > > Le sam. 25 juil. 2026 à 11:28, Ihor Radchenko <[email protected]> a écrit > > : > > > > > > Earl Chase <[email protected]> writes: > > > > > > >> We also need other similar commands. For example, org-agenda-todo-at. > > > >> > > > > > > > > I added `org-agenda-todo-at' as a separate patch. Both > > > > `org-agenda-todo-at' and `org-todo-at' only use the interactive > > > > version of `org-read-date' when they are called interactively. > > > > > > The way it is implemented feels like too much copy-pasting. > > > Maybe we can extend org-todo itself to accept optional argument TIME > > > that can be nil (current time), 'query - query interactively, or a > > > string - time to be used. Then, the code will be less repetitive I think. > > > > > > Also, I noticed that time is forced to be present even when I do not > > > enter it, and defaults to current time. It does not feel right. Maybe we > > > need to put 00:00 or something. > > > > > > > But > > > > the specific problem that I was referring to is more complicated than > > > > that. In addition to the `org-todo-at' patch and the > > > > `org-agenda-todo-at', I created another patch with a simple test that > > > > shows why this approach makes it impossible to test `org-todo-at' with > > > > repeaters, for the moment at least. You will see that when you call > > > > `org-todo-at', LAST_REPEAT gets set to the correct value but the > > > > repeater itself is not set to the right value. I still haven't found > > > > the root cause of this issue. But I do know that LAST_REPEAT is always > > > > set to the correct time because `org-auto-repeat-maybe' directly uses > > > > `org-current-effective-time' to create the new value of LAST_REPEAT. > > > > On the other hand, `org-today' and `org-timestamp-to-now' are the > > > > functions that `org-auto-repeat-maybe' uses to actually update a > > > > repeater. Those functions of course can be overridden. But I think a > > > > better idea would be to create org versions of `time-to-days', > > > > `time-since' and `float-time', as those are the functions that > > > > `org-timestamp-to-now' and `org-today' uses internally. I still don't > > > > understand why none of that is needed for manual tests. > > > > > > Yes, that would make sense. > > > (And yes, this is why this patch is less trivial that one may think; > > > especially if we want to support effective time across Org) > > > > > > > In order for org to properly support effective time, we need the following: > > > > - org-time-since > > - org-float-time > > - org-time-to-days > > - org-decode-time > > - org-current-time-string > > - org-format-time-string > > - org-time-less-p > > - org-time-equal-p > > - org-time-add > > - org-time-subtract > > > > The issue is that besides `org-time-to-days', > > `org-current-time-string', `org-time-equal-p', all of the functions in > > the above list are currently obsolete function aliases. So I'm not > > sure what the process for un-obsoleting functions is, but that is one > > of the things that will have to be done here. > > > > Obviously once those functions are written, they will need to be used. > > So we will have to go through the org code and replace all time-* > > functions with org-time-* functions. It would also need to be made > > clear to contributors that they need to use org-time-* functions for > > any new code. > > > > Then, I think the next step should be to combine `org-current-time' > > and `org-current-effective-time'. The current state where we have both > > functions is very confusing. Just based on the way custom variables in > > org-mode usually work, you would expect `org-use-effective-time' and > > `org-extend-today-until' to directly override `org-current-time'. > > Instead those variables, indirectly override `org-current-time' via > > `org-effective-time' More importantly, if the goal is to support > > effective time throughout Org, we are going to end up replacing almost > > every single use of `org-current-time` with > > `org-current-effective-time' anyways. But that's a minor issue, a > > quick search of the org code shows that the reason most of the > > org-mode ignores effective-time for the moment is due to the use of > > functions like `time-add', `time-to-days', `time-since', etc.
