accounting is wrong on reload if tasks have a short (< 1 minute) interval
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GTimeLog |
Fix Released
|
High
|
Unassigned |
Bug Description
How to reproduce:
1. open gtimelog
2. Type 'started'
3. Wait for a few minutes
2. Type 'foo', press Enter
3. In a few seconds (before the minute in the system clock changes), type 'bar', press Enter
4. You'll see something like:
0 h 1 min (17:20-17:21) started
0 h 3 min (17:21-17:24) foo
0 h 0 min (17:24-17:24) bar
(that's the expected behavior)
5. Press Ctrl+R to reload timelog.txt
6. You'll now see:
0 h 1 min (17:20-17:21) started
0 h 3 min (17:21-17:24) bar
0 h 0 min (17:24-17:24) foo
(the ordering of 'foo' and 'bar' is reversed, and the time accounting is now wrong)
I don't mind having the precision of the accouting being just 1 minute, but the ordering shouldn't break on reload (it should always account the 'foo' task as taking a few minutes and the 'bar' task as taking 0 minutes).
Related branches
Changed in gtimelog: | |
status: | Fix Committed → Fix Released |
Ouch.
Fixed in trunk. I'm planning a new release soon (version 0.5).