andrea@fedeli.eu writes:

>    #+PROPERTY: Effort_ALL 0 0:10 0:30 1:00 2:00 3:00 4:00 5:00 6:00 7:00
>
>    #+COLUMNS: %30ITEM(Task) %30Effort(Estimated Effort){est+} %CLOCKSUM
>...
>    Originally produces
>    image.png
>    That shows that days and months are wrongly counted the same

Thanks!
Confirmed.

>    > The matter is related to the fact that org-columns--summary-estimate, from org-colview.el, uses function string-to-number to take value on ranges; acting this way

>   Both issues can be very simply addressed by adoption of org-duration-to-minutes as
>
>   input adapted and org-duration-from-minutes as output adapter.
>   A similar concern affects also the simpler case of a single value instead of a range (second pcase branch)

This will not be backwards-compatible.
Some people may abuse this summary type to count something that is not
time, like cost.

We rather need something like the attached diff.
However, this will use `org-duration-format', which may not always be
desirable - the default value will force days even when all the estimates
are months:

3m
3m-4m
---
180d 0:00 - 210d 0:00