timew reports incorrect total tracked time

[Devin Trowbridge]

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

[Scott Mcdermott]

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 (?)

[Devin Trowbridge]

yeah, your description of Current is accurate. Current time is not my issue though, Total is.

[Scott Mcdermott]

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) ?

[Scott Mcdermott]

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...

[Devin Trowbridge]

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.

[Thomas Lauf]

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).

[Devin Trowbridge]

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.