accounting is wrong on reload if tasks have a short (< 1 minute) interval

Bug #708825 reported by Eduardo Habkost
6
This bug affects 1 person
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

Revision history for this message
Marius Gedminas (mgedmin) wrote :

Ouch.

Fixed in trunk. I'm planning a new release soon (version 0.5).

Changed in gtimelog:
status: New → Triaged
importance: Undecided → High
status: Triaged → Fix Committed
Revision history for this message
Eduardo Habkost (ehabkost) wrote :

Thanks! I just updated to latest trunk and I confirm that the bug is fixed.

Changed in gtimelog:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.