> Would it make sense to move some of this logic to org-duration.el? If the format should be as specified in org-duration.el, then it makes sense this should be managed there. It seems the intent is for org-duration.el to serve as an API for dealing with durations generally which is another reason for using it. > org-duration-to-seconds could implemented in org-duration.el. There's already org-duration-to-minutes there so it seems natural. The checking you describe could also be done there too, so org-timer could just pass the duration it gets (from effort estimates, point, minibuffer,…) as a string directly to org-duration-to-seconds, which performs checks are returns seconds/nil/signals errors as appropriate.
I agree with you. But I think that should be done after we confirm effort estimates are properly handed. Le sam. 4 juil. 2026 à 05:04, Paul Bryan <[email protected]> a écrit : > > That means that we can simplify > the process of creating a timer for an > effort value if we follow the following plan: > > Would it make sense to move some of this logic to org-duration.el? If the > format should be as specified in org-duration.el, then it makes sense this > should be managed there. It seems the intent is for org-duration.el to > serve as an API for dealing with durations generally which is another > reason for using it. > > org-duration-to-seconds could implemented in org-duration.el. There's > already org-duration-to-minutes there so it seems natural. The checking > you describe could also be done there too, so org-timer could just pass the > duration it gets (from effort estimates, point, minibuffer,…) as a string > directly to org-duration-to-seconds, which performs checks are returns > seconds/nil/signals errors as appropriate. > > – Paul > > * From*: Earl Chase <earl+chase+%[email protected]%3E> > * To*: Diego Ezequiel Vommaro <[email protected]> > * Cc*: [email protected] > * Date*: Fri, 3 Jul 2026 10:05:26 -0500 > * Subject*: Re: [BUG] org-timer-set-timer fails when effort is larger > than 60 minutes [9.8.6 (release_9.8.6.dirty @ > /home/diego.vommaro/Documents/Home/repos/org-mode/lisp/)] > > This is a good start. While your patch technically fixes the problem, I > don't think you actually got to the root of the issue. If we focus just on > how `org-timer-set-timer' converts an effort value into seconds, we see > that `org-duration-to-minutes' is used to convert the value into minutes, > ":00" is appended to those minutes, that value is converted into a > "h:mm:ss" duration and finally that value is converted into a number of > seconds. It seems that this is done so that effort values can be handled > the same way as prefix values or values that are read from the minibuffer > even though none of that is necessary for effort values. > > This is from the docstring of org-effort-property: "Effort estimates given > in this property need to be in the format defined in org-duration.el". That > line is referring to `org-duration-format'. That means that we can simplify > the process of creating a timer for an effort value if we follow the > following plan: > > 1) For timers that are set via the effort property, we should first > confirm that the user has not changed the value of `org-duration-format' > and then we should use `org-duration-h:mm-only-p' in order to confirm that > the value is in the "h:mm" format. > 2) If both those checks pass, we can directly append ":00" to that value > and then pass it to `org-timer-hms-to-secs'. > 3) If they haven't changed the value of `org-duration-format' and the > value of their effort property is not properly formatted, we should throw > an error that lets the user know that their effort value is not properly > formatted. > 4) If the user has changed the value of `org-duration-format' we should do > something like (org-duration-from-minutes (org-duration-to-minutes effort) > 'hh:mm:ss) in order to get an effort value that is formatted in the > "h:mm:ss" style. Then, that value can be passed directly > to `org-timer-hms-to-secs' or we throw an error if the value can't be > converted. > > Let me know what you think. > > Le lun. 29 juin 2026 à 05:09, Earl Chase <[email protected]> a écrit : > >> Owned. I will take a look at this. >> >> Le dim. 28 juin 2026 à 23:21, Diego Ezequiel Vommaro < >> [email protected]> a écrit : >> >>> >>> Remember to cover the basics, that is, what you expected to happen and >>> what in fact did happen. You don't know how to make a good report? See >>> >>> https://orgmode.org/manual/Feedback.html#Feedback >>> >>> Your bug report will be posted to the Org mailing list. >>> ------------------------------------------------------------------------ >>> >>> Hi all, >>> >>> Given a task with an effort larger than 60 minutes, then >>> org-timer-set-timer sets the countdown timer to 0. >>> >>> For instance, for a task like this >>> ***** NEXT complete action items >>> :PROPERTIES: >>> :Effort: 2:00 >>> :ACTIVATED: [2026-06-25] >>> :END: >>> >>> the resulting countdown timer is 0 when C-c C-x ; >>> >>> I have dived into the issue and found that the string of the seconds >>> part is wrongly >>> added when the count is larger than 60 minutes. I applied the >>> following patch to get it to work >>> >>> (when (string-match "\\`[0-9]+\\'" minutes) >>> - (setq minutes (concat minutes ":00"))) >>> + (let* ((total (string-to-number minutes)) >>> + (A (/ total 60)) >>> + (B (% total 60))) >>> + (setq minutes (format "%d:%02d:00" A B)))) >>> >>> I tested for the following cases and behaved as expected: >>> >>> :Effort: 2:00 (120 minutes) >>> :Effort: 1:00 (60 minutes) >>> :Effort: 0:30 (30 minutes) >>> :Effort: 60:00 (3600 minutes) >>> :Effort: 101:00 (6060 minutes) >>> >>> Hope it can help to solve the issue. >>> >>> Thanks, >>> Diego Ezequiel Vommaro >>> >>> Emacs : GNU Emacs 29.3 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo >>> version 1.18.0, Xaw3d scroll bars) >>> of 2024-04-01, modified by Debian >>> Package: Org mode version 9.8.6 (release_9.8.6.dirty @ >>> /home/diego.vommaro/Documents/Home/repos/org-mode/lisp/) >>> >>>
