Re: [O] [bug?] Computations on efforts expressed in days

[Sebastien Vauban]

Hi Bastien,

"Sebastien Vauban" wrote:
> Bastien wrote:
>> Sebastien Vauban writes:
>>
>>> I want to compute efforts given in days. As explained by the doc of
>>> `org-effort-durations', we must add a =d= modifier to tell Org that given
>>> numbers must be multiplied by 480 (in the case of hours) to get the
>>> correct number of corresponding minutes.
>>>
>>> I did that, but (as shown in the following inlined ECM):
>>>
>>> - the computed total for task A is interpreted as hours (4.5 days becomes
>>>   4 hours 30 minutes).
>>>
>>> - the grand computed total for all tasks becomes completely wrong (4:38
>>>   instead of 4.5 + 0.125 = 4.625 days).
>>>
>>> Am I doing something wrong, or forgetting something?
>>
>> This should be fixed now.
>
> With your patch, the dynamic bloc now becomes:
>
> #+BEGIN: columnview :hlines 1 :id "75dd37bf-a15a-4910-89f8-25d481f3e523" 
> :maxlevel 3
> | Task        | Estim. |
> |-------------+--------|
> | * Tasks     |  37:00 |
> | ** TODO A   |  36:00 |
> | *** TODO A1 |   1.5d |
> | *** TODO A2 |     3d |
> | ** TODO B   | 0.125d |
> #+END:
>
> All the computations are right now -- thanks a lot.

The above computations are right, as said, but looking further, I see another
problem:

- while totals are correctly taking care of the effort in "days",

- subcomponents are not: tasks A1 and A2 here below: respectively 1 and 3
  seconds, instead of 1.5 and 3 days...

  #+BEGIN: columnview :hlines 1 :id "75dd37bf-a15a-4910-89f8-25d481f3e523" 
:maxlevel 3
  | Task        | Estim. |          |
  |-------------+--------+----------|
  | * Tasks     |  37:00 | 37:00:00 |
  | ** TODO A   |  36:00 | 36:00:00 |
  | *** TODO A1 |   1.5d | 00:00:01 |
  | *** TODO A2 |     3d | 00:00:03 |
  | ** TODO B   | 0.125d | 00:00:00 |
  #+TBLFM: $3=$2;T
  #+END:

> However, the table is difficult to read, mixing hours and days (in this
> case). Shouldn't we be able to give a parameter to the columnview to say in
> which format we expect the times, and then get *all* values converted to
> either hours or days (still, in this case)?

This becomes even more stringent if you plan to make a "CLOCKED vs Estimated"
report where figures of one column are in hours and figures of the other are
in mixed units (days or hours).

Best regards,
  Seb

-- 
Sebastien Vauban