BUG: Due Date and Hours sync without considering prefs Time Periods

[TonyG]

I'm working with the Gantt chart. I originally set tasks with a Due Date, intended as an Estimated Due Date. My default Time Estimate units is Hours. So for a task of 22 days, with my preference set to do so, the Time Estimate was set to 528 hours. But 528 hours = 22 x 24 hour days. In preferences>Time Periods, I have one day is 8 hours and a week = 5 days. So I think that calculation for hours should be more like this:

In the 22 days, remove all of the non-work days as set in preferences. With my specific dates that leaves 16 work days.

Now 16 x 8 hour days = 128 hours.

Similarly, if I set the time estimate to 128 Hours, it's calculating 24 hour days, resulting in 3 week days plus 2 weekend days.

So I think that calculation should follow the same pattern.

Thanks.

[TonyG]

Looking at this a bit, I see what's happening, but I wanted to add some more info.

My time estimate default period is H=hours. That's total hours. The date/estimate conversion is doing exactly what it was asked to do. It converted D days into H total hours.

If I wanted my estimates in 'd' work days I should have set that as the units before I started. Then it would have calculated the number of work days. To get H hours now, by changing to 'd' units and accepting the recalculate, it would use 8 hours per day to do the right calculation.

However, when doing that, the Due Date then syncs with the estimate, still using 24 hour days. So you see, that calculation is going both ways. To get around this, I disabled the sync, changed all of my units (in tree view) then re-enabled sync, then poked each estimate to trigger the date update.

What I'm hoping to see here is a correction to that calculation handling, and/or a more intuitive way to change the units, without having to go back and change every task in a project. For example, if the estimate says 3d and the dates are set 12/15-12/17 and I change that to 4d. It should recognize that (for a made up example) that the 12/18-19 are the weekend and we're using 'd', so the fourth day should set the due date to 12/20. When converting the 4d to H, it should see that as 4*8H = 32H. But leave the dates the same, since this recalculation for the units isn't changing the actual time period. And if I set to 33H, that shouldn't set the due date to start+2 (24 hours + 9), because the time period is still 8/day.

Thanks for your consideration.

T

[.dan.g.]

Thx Tony, the current behaviour is kind of a legacy from when weekdays didn't exist but I wholly agree with your opinion.

When auto-calculating task time estimates in hours or minutes after moving the start or due date, it should always be assumed that we are dealing with actual workday durations.

I'll get it fixed for the next update.

[TonyG]

Thank you VERY much, Dan. You've summarized it much more effectively than my long-winded note.

Today I'm looking at a workday which has tasks assigned to fill all 24 hours. Yes, all we need is to figure in workdays.

I'll be happy to beta changes if desired.

Best,

T

[.dan.g.]

Fixed in 7.2.4

On Friday, 25 January 2019 11:26:56 UTC+11, TonyG wrote: