GNOME Bugzilla – Bug 584626
Duration miscalculates with "until" hours. (while the "for" works correctly).
Last modified: 2009-06-08 12:12:34 UTC
Please describe the problem: Duration works correctly with "for" hours even when the task goes past the midnight, but goes wrong upon resaving. The default "until" hours miscalculates it if the end time overlaps into next day. Steps to reproduce: 1. From the overview window, (add or) edit an existing task and start it at 18:00 hours and select "for" 6 hrs 30 min as duration. Save it and look at the overview. It shows the duration as 06:30 which is correct. 2. Now open the same task by double clicking it (and optionally make a minor change to the description) and save it again. Actual results: 3. Now look at the overview, it now shows the duration as 06:06 which is wrong. Basically when you resaved it, it was defaulting to the "until" hours that makes it calculate differently. Expected results: The "for" and the "until" should work correct and consistent. If you actually want to split the task into two days, it should happen correctly with "for" and "until" as well. (Whatever you decide, it should be consistent). Does this happen every time? Yes Other information: Thanks for this wonderful little tool! I like it and use it everyday!
I wonder - in git master we have solved the whole midnight business by not splitting up the task and calculating proper daily totals instead. Fixing this bug will be quite a drag, and situations when it exposes itself are not so common, so maybe we could just live with this in 2.26
Not splitting a task after midnight is good. Please just make sure the "until" also shows correct duration just like the "for" does. No hurry though. Thanks.
well, there is no "until" nor "for" anymore, just end time
(In reply to comment #3) > well, there is no "until" nor "for" anymore, just end time > I see what you mean. I have installed 2.27.3 just now by following the installation instructions from your blog post. Thanks. It has now automatically split my last nights 6 hrs 30 min task into two separate tasks of one with 6 hrs duration and another with 30 min duration. Both the tasks contain 18:00 hrs as start date and 00:30 as end date in yesterday's date (June 01) and the second task is listed under today's date (June 02). I wish a new day begins at 6:00 AM in the morning! It's a crazy world for night owls like me!! :) The new version looks great. I am looking forward to the ability to tweak what we see in a Report (selecting columns etc.,). Thanks.
Satya: Haha! That's exactly what I thought today and have already started working on an implementation. Not sure Toms will like it as much as I do :)
Patryk's patch: http://mail.gnome.org/archives/hamster-applet-devel-list/2009-June/msg00000.html My main concern is that this introduces a new day term (which starts at hour other than 00:00), which might cause confusion and so does complicate things a little, for the benefit of not willing to acknowledge midnight as the moment where days change. But hey, this is a small thing and it seems that i've been talking about it more than i care, so, Patryk, let's just go for it!
- WHERE (date(a.start_time) >= ? and date(a.start_time) <= ?) - OR (date(a.end_time) >= ? and date(a.end_time) <= ?) + WHERE a.start_time >= ? and a.start_time <= ? I'm afraid you have shaved off something here. see bug 574334 comment 2
Toms: That was intentional to get rid of splitting activities in two. Each activity is always counted towards the day it was started on, otherwise you'd get the same tasks counted for each day they span. It should behave as expected until someone starts to track 24+ hour long tasks at which point old code was buggy too (it always split in two, even if tasks spanned 3+ days). I don't think we expect people to track tasks measured in days.
So if a task goes from 5am until 12am (say, early morning), and you have set to change days at 6am, then the task will belong to yesterday?
Yes, it's up to you to set the splitter to some sensible time. Splitting wouldn't make thing prettier anyway. Unless you want me to assign activities to the day where most of their duration happens, that should be easy enough (again, unless someone tracks a 48+ hour activity).
Hmmm, actually that is a terrific idea!
Created attachment 135865 [details] [review] Proposed solution Here you go, assigns tasks to the date where most of the task was done (or the first day in case of multiday activities). Please test but don't commit, I'll push my branch when ready.
Changes pushed to git master. 5:30 am is the default splitting time for now. In the future we might make it configurable. Leaving the original bug as confirmed, 2.26 as the only stable branch is still affected.
(In reply to comment #13) > Changes pushed to git master. 5:30 am is the default splitting time for now. In > the future we might make it configurable. You guys are awesome! Thank you!! :) This is a radical feature! It will be even more beautiful when it's configurable!!
hmm, basically this is fixed in 2.27 and a won't fix for 2.26, so marking it as such