timew reports incorrect total tracked time
devintrowbridge opened this issue · comments
I'm on WSL2 running Ubuntu. timewarrior
seems to be reporting the incorrect total time, but only when calling the default command. Summaries and reports seem unaffected. Here's some output
Actual output
devin:~$ timew
Tracking
Started 2022-10-03T16:00:00
Current 46:33
Total 32:24:53 <<<< This is wrong
devin:~$ date
Mon Oct 3 16:46:38 CDT 2022
Expected Output
devin:~$ timew
Tracking
Started 2022-10-03T16:00:00
Current 46:33
Total 0:46:33 <<<< This is right
devin:~$ date
Mon Oct 3 16:46:38 CDT 2022
Also note that summary
and other report commands are unaffected.
devin:~$ timew summary :day
Wk Date Day Tags Start End Time Total
W40 2022-10-03 Mon 8:00:00 14:00:00 6:00:00
16:00:00 - 0:52:49 6:52:49
6:52:49
interesting, not sure what Current
actually means, it doesn't add up to anything I can figure out. Total
is the time for the current [open] interval.
looks like "Current" corresponds with the minutes component of the current time? FWIW the code looks like this:
if (interval.is_open ())
{
out << "Tracking " << tags << '\n'
<< " Started " << interval.start.toISOLocalExtended () << '\n'
<< " Current " << minimalDelta (interval.start, Datetime ()) << '\n'
<< " Total " << std::setw (19) << std::setfill (' ') << total.formatHours () << '\n';
}
and then this minimalDelta is [showing the trailing] components of the current time that have changed since the start time, apparently (?)
yeah, your description of Current
is accurate. Current time is not my issue though, Total
is.
Current time is not my issue though, Total is.
Ok right, so Total is this total.formatHours()
, I guess that's doing like this:
time_t t = _period;
int seconds = t % 60; t /= 60;
int minutes = t % 60; t /= 60;
int hours = t;
std::stringstream s;
s << hours << ':'
<< std::setw (2) << std::setfill ('0') << minutes << ':'
<< std::setw (2) << std::setfill ('0') << seconds;
That's from libshared, looks right to me? C will truncate integer division and time_t should be an integer type, so the modulo gets the remainder, the kept part is carried to the next one, perhaps missing something...
I'm unable to reproduce the issue you have myself, my totals always look correct as far as I can tell? Are you using the latest released version of timewarrior (1.4.3) ?
Are you using the latest released version of timewarrior (1.4.3) ?
that code doesn't look to have changed since 2016 so the version is probably not it...
My problem has inexplicably fixed itself as of this morning?? Maybe it saw I opened an issue, and decided to act right...
I can't reproduce at this point either so I'm happy with closing this for now.
Versions previous to 1.4.0
contained a "feature" that summed up all consecutive intervals with the same tag set.
So if you have interval FOO
(with e.g. 1h duration) as the latest interval in your database and start a new with FOO
, then the output 5min later then was
Tracking FOO
Started 2022-10-03T16:00:00
Current 5:00 <<< the current interval
Total 1:05:00 <<< the sum of all intervals with the same tag set
So, when you are using a pre-1.4.0
version, I would assume you had at least one interval with no tags (also qualifies as a tag set) in your database when you starting tracking and whose duration(s) got summed up.
When it healed itself, I assume you had tracked a different tag set before, so Timewarrior only summed up your newly started interval.
As this "feature" rather caused confusion than helped, it was removed with version 1.4.0
(👉🏻 release notes).
I had wondered if it was summing up previous intervals for the tag. I upgraded to v1.4.0
and haven't see it since.
For posterity, I think @lauft has the definitive answer above.