Axel Kielhorn <org-m...@axelkielhorn.de> writes: >> Am 20.05.2021 um 19:58 schrieb Nicolas Goaziou <m...@nicolasgoaziou.fr>: >> >> Org Duration is strict about what it is fed with (which is good). Effort >> property expects a duration as value. But "3-8" is not a valid duration. >> However, "3" is a valid duration; it means 3 minutes. > > The problem is that effort can either be a duration and in that case the > strict duration library ist fine. > Or it can be a range (of days).
No, it means minutes. However, units do not matter in "est+". You can interpret the result in days if it matters. > 3:30 is fine when : is used to add the times > 3.0 - 4.0 is a range estimate when est+ is used > 3:00 - 4:00 is only correct by chance, 3:30 - 4:30 will lead to the > same result since est+ does not handle durations. This is what I'm suggesting, isn't it? > Splitting it into 2 properties (effort and effort_range) is even worse > since it will be inconsistent after a few edits. This is _not_ what I'm suggesting. > It gets even more interesting when on task has 3-4 (implicit) days, while > another has 8:00 (implicit) hours. > (Are 8 h one work day, or are 24 h one calendar day?) Org Duration library is able to distinguish canonical from user-provided units (see last argument in `org-duration-to-minutes). Actually, Org Colview makes this distinction by calling "canonical" duration an "age" (see "@min" and other operators). There could be est+ and est-age+ (or anything else, really). >> Maybe Effort property should simply accept a duration or a duration >> range. > > That’s what I first thought it would do, since a duration is a time (8:00 for > 8h). > The question is how to resolve ambiguity? I don't see any ambiguity. est+ can be changed to accept 2d-3d. > 1.0 is one day No, it's one minute. 1.0d is one day. > 1:00 is one hour > 1 is one minute, really? yes, that is the default for the duration > library. But it used to mean one day??? A long time ago, yes, but that was inconsistent. > Maybe a new est: function to work with durations and the old est+ function to > work with numbers > (which could mean days, but it could mean ms as well)? And a warning about > inconsistent units. I don't think this is needed. The current est+ is not working anyway. > What happens when I use a range in a clock table? Who knows? :) > But since the feature is advertised it would be great if it works. There's no reason it cannot work. It just needs some love. Regards,
