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 149651 - Work set via gantt row can exceed arbitary limit (10,000) defined in Task dialog work.
Work set via gantt row can exceed arbitary limit (10,000) defined in Task dia...
Status: RESOLVED NOTABUG
Product: planner
Classification: Other
Component: General
0.12
Other All
: Low minor
: 0.13
Assigned To: Lincoln Phipps
planner-maint
Depends on:
Blocks:
 
 
Reported: 2004-08-08 17:13 UTC by Lincoln Phipps
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Lincoln Phipps 2004-08-08 17:13:52 UTC
This was found in testing and will be fixed by me as part of the
planner-gantt-row year 2038 overflow fixes.

If you use the gantt to set work for tasks so they go far-in-the-future then its
possible to get the work figures >10,000 if you have more than 1 resource
allocated to the task. 

A single resourced task would hit the year 2038 limit with around 8700 work days
but if you set two resources then you can get the work over 10,000 - which is
what we have arbitarily defined as a limit (and I see no reason why we shouldn't
stay at that limit.
Comment 1 Lincoln Phipps 2004-08-08 17:20:14 UTC
This was discovered BECAUSE I fixed another bug with mrp-task-manager.c in the
work calculations. An overflow bug caused work figures of around 1400 days to
wrap around so you couldn't reliably add large work values anyway. The
calculation was (x * y /100) but I've fixed it to be 

(x /100.0) * y 

and as casting to float is not expensive as its only done once or so per task
but it doesn't wrap now and thus allowed me to add huge amounts of work to tasks
(limited by the duration hitting 1st Jan 2038 which is where I've stopped the
end dates).

Comment 2 Richard Hult 2004-10-02 10:26:16 UTC
I'm closing this since it's not right to impose an arbitrary limit like this. We
should just "chop off" dates at the end date.