> 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). 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. Splitting it into 2 properties (effort and effort_range) is even worse since it will be inconsistent after a few edits. Some functions only expect 1 value for the effort, which is the correct value? What happens when I : add a range? The dynamic block code juggles with conversion to minutes, which is wrong when a range is involved. 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?) > 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? 1.0 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??? 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. What happens when I use a range in a clock table? The more I think about that, the more questions I have. To be honest, I’m not even sure I will use the est+ function in real life. (I discovered it when preparing some training material and thought that was interesting.) I’ll probably just : add the hours and add 10% safety margin on top. But since the feature is advertised it would be great if it works. Would I be sorry if you deprecate this feature? Probably not. Will anyone notice? Probably not, it has been broken for 4 years. Greetings Axel
