After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 155496 - Task cost calculation does not reflect actual length of day
Task cost calculation does not reflect actual length of day
Status: RESOLVED DUPLICATE of bug 134383
Product: planner
Classification: Other
Component: General
0.11
Other Linux
: Normal normal
: ---
Assigned To: planner-maint
planner-maint
Depends on:
Blocks:
 
 
Reported: 2004-10-15 11:22 UTC by David M. Swain
Modified: 2005-10-13 20:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David M. Swain 2004-10-15 11:22:21 UTC
Having set up a working day of 7.5 hours and a cost of 10 with a task duration 
of 5 days the calculated cost in the Task page is 400 this should be 375 as I 
have set up a 37.5 hour week. The cost calculator should take into account the 
actual length of the working day not default to 8 hours.

This is using KDE V3.2 branch 20040204
Comment 1 Richard Hult 2004-10-17 21:55:04 UTC
We have actually been discussing how to handle this. One suggestion was to have
a separate setting for default working day length and use that for those
calculations and other places where we need hour <=> day conversion etc. What do
you think about that solution?
Comment 2 David M. Swain 2004-10-18 09:38:27 UTC
I don't see why you need to keep the default working day length, surely once 
the 'real' working day length has been set up all project and task calculations 
should be done using the new 'real' length. So why not just change the working 
day from the initial 8 hours to the 'correct' project day length and leave it 
at that?

Comment 3 Richard Hult 2004-10-18 14:57:16 UTC
The problem is that there is no "one true" length, since it depends on which
calendar is used. So two different resources can have completely different
working hours, for example. This shouldn't really affect the conversion from
hours to days, imo.
Comment 4 David M. Swain 2004-10-18 16:25:06 UTC
True, I suppose each calendar will have to have a working day length and all 
calculations will have to cross reference the calendar data to ensure the 
correct values are calculated, then if one is required a general 'default' day 
length of whatever is set up in the project (presumably thedefault calenday day 
length) can be available to initialise the default calendar day value.
Comment 5 Richard Hult 2005-02-18 22:44:20 UTC
This should be a lot easier to fix now, since there is only one place to change
(planner_format/parse_duration).
Comment 6 Richard Hult 2005-10-13 20:19:35 UTC

*** This bug has been marked as a duplicate of 134383 ***