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 165948 - Wrong report when work day <> 8 hours
Wrong report when work day <> 8 hours
Status: RESOLVED FIXED
Product: planner
Classification: Other
Component: General
0.12
Other Linux
: Normal major
: 1.0
Assigned To: planner-maint
planner-maint
Depends on:
Blocks:
 
 
Reported: 2005-02-01 17:18 UTC by Cosmin Pop
Modified: 2008-01-19 21:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Cosmin Pop 2005-02-01 17:18:26 UTC
First, set up a working day of 7.5 hours.
Whenever I try to create a task taking 10 days (for example), I end up with a
10d 5h task. If I switch to Gantt Chart and try to modify the work
(double-click/Enter in the 'Work' field), but don't modify and press 'Enter'
again, the field would "grow". Subsequent 'enter's would only increase this value.
Also, in the exported HTML file, the 10 days task (which appeared in the Gantt
Chart as having 10 days and 5 hours) is only taking 9d 3h.

NOTE: The 7.5 hours work day is not unusual. I work for a canadian company that
has a work day of 7.5 hours. I also worked before for a french company. They
also had a reduced work day. When I left the french company, their government
was thinking about having a 7.25 hours work day!! :)
I can't just use an 8 hours work day. Each month we generate a report saying how
many hours we spent on each project.
Planner seems to take the 8h work day for granted! But it's not...
Comment 1 Arto Määttä 2005-02-14 17:21:25 UTC
I noticed this same bug and it makes the use of Planner for me impossible. If 
anyone wants an example of project that shows this bug, I can send mine.
Comment 2 Maurice van der Pot 2008-01-19 21:02:44 UTC
I have been unable to reproduce this in any version from 0.13 onwards. If the problem still exists, please reopen this bug.