[bug?] Computations on efforts expressed in days

[bug?] Computations on efforts expressed in days

[Sebastien Vauban]

Hello,

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?

Best regards,
  Seb

--8<---------------cut here---------------start------------->8---
#+COLUMNS: %66ITEM(Task) %6Effort(Estim.){:}
#+TITLE:     ECM Proposal
#+AUTHOR:    Seb Vauban

* Tasks
  :PROPERTIES:
  :ID:       75dd37bf-a15a-4910-89f8-25d481f3e523
  :END:

** TODO A

*** TODO A1
    :PROPERTIES:
    :Effort:   1.5d
    :END:

Time required: 1.5 days.

*** TODO A2
    :PROPERTIES:
    :Effort:   3d
    :END:

Time required: 3 days.

** TODO B
   :PROPERTIES:
   :Effort: 0.125d
   :END:

Time: around 1 hour.

* Budget estimate

We have estimated the budget as follows:

#+tblname: dblock-tasks
#+BEGIN: columnview :hlines 1 :id "75dd37bf-a15a-4910-89f8-25d481f3e523" :maxlevel 3
| Task        | Estim. |
|-------------+--------|
| * Tasks     |   4:38 |
| ** TODO A   |   4:30 |
| *** TODO A1 |   1.5d |
| *** TODO A2 |     3d |
| ** TODO B   | 0.125d |
#+END:
--8<---------------cut here---------------end--------------->8---

-- 
Sebastien Vauban

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

[Bastien]

"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> 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.

Thanks,

-- 
 Bastien

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

[Sebastien Vauban]

Hi Bastien,

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.

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)?

If that existed, should it be done for Effort only, or extrapolated to all (?)
properties?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [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