Report: summing the times doesn't give the same results as the in app total about trackworktime HOT 15 CLOSED

The times shown in the app are calculated by the method TimeCalculator.calulateOneDay(DateTime, List). The export data comes from TimeCalculator.calculateSums(DateTime, DateTime, List). You are welcome to investigate - and maybe write a unit test for it?

from trackworktime.

Thanks for the excellent bug report! It's right, there is a difference of one minute per work day (if only one task was clocked). It seems that the report doesn't count the clock-out minute but the UI does.

from trackworktime.

Thanks for you app, it's a bliss to not have to do anymore my timetracking on a PC :-D

Each week, I had to add a correction. Here are the amount to correct per week

• 0.11666600000000216 7 min
• 0.38333400000000495 23 min
• 0.4333333299999964 26 min
• 0.6333333999999979 38 min
• 0.4833333699999969 29 min
• 0.9333333699999997 56 min
• 0.9666666669999984 58 min
• 0.8666666699999936 52 min
• 1.5833333 1h35min
• 0.733333330 44 min

That's a lot :)

It's not one minute per work day but it's round to the minute if that helps.

from trackworktime.

In my case, it was one minute per work day, and I had only one task. How many tasks and how many check-in/check-out cycles did you have in the mentioned weeks? Is there any correlation?

from trackworktime.

For the week with 1h35min I have 348 event across 10 tasks. I don't see any obvious correlation.

Here is the anonymized report
week-starting-2017-11-27.ods.zip

What else can I do to help you?

from trackworktime.

Would privately sending you a full oandbackup of my app data help?

from trackworktime.

I'm sorry, but I don't know when I will have the time to look into this. But before requesting your full data, I definitely would need to analyze the anonymized report you attached and look into the code. Maybe the issue is already solved after that - if not, I'd come back and ask for your full data. Perhaps you could do the export and put it aside for possible future use?

from trackworktime.

Hi, I still have this issue. Where could I check in the code to compare how are the both sums made?

from trackworktime.

For the week with 1h35min I have 348 event across 10 tasks. I don't see any obvious correlation.

There are 143 out events. When a truncation occurs, the average lost is 30sec if I'm correct.
Then 71.5 min → 1h11.5 min would be lost. Which should be compatible with 1h35 due to variance.
So it's likely to be truncation.

Here are the places where there are truncations:

There might be others ^^

from trackworktime.

I'm testing a PoC of a fix[1] and I can say that it works. The only remaining truncations seems to be the ones on each task (each line in the report), so a rounding before int conversion should make the reports almost exactly match the weekly sum in the UI. (unless we have no luck and the rounding are always in the same direction, but it shouldn't matter at this point)

Also, the flexitime sum is impacted by this bug.

[1] Do you have advices about how to add tests for this? Where to start? Similar tests that would allow to test the time places in the code pointed in the previous message.

from trackworktime.

That's good news, thanks for your work!
You are welcome to add unit tests (like this) or integration tests (like this) to the project. I think the best point to start would be the TimerManager, it can be used with mocks via constructor injection.

from trackworktime.

@tuxayo Much has happened since, the app is at v1.1.8 currently and has a reworked calculation engine. Could you please check if the error still exists? I'm optimistic that it's fixed now - but if not, would you consider to create a PR with your fix (adapted to the current codebase)?

from trackworktime.

Could you please check if the error still exists?

I just migrated from my custom 1.0.5 to release 1.1.9. I'm sure it's fixed:
I did screenshots of the 12 past weeks and at most there was once a 3 min of offset between the latest build and my old with the fix. Most of offsets are 1 and 2 min.
On a whole week with hundreds of events each week.

It doesn't tell which one is right but it tells there isn't the same issue as it used to create a larger offset.

It doesn't tell if there is an offset with "reality"
I'll try to do parallel time tracking with a stopwatch software on PC and see if there is a significant offset with TWT and will open a new issue if there is concerning stuff.

BTW, new version is awesome, it very responsive. The old one needed more than 1 second of processing when displaying the week view. So when coming back from editing an event, when changing week, opening the app.
And that was linear to the total number of time data in the app. So it was only getting worst ^^"

from trackworktime.

I did screenshots of the 12 past weeks and at most there was once a 3 min of offset between the latest build and my old with the fix. Most of offsets are 1 and 2 min.

I'm completely wrong, I compared the in app weekly totals. Not the exports... Got confused since I don't used reports anymore.
l'll check that.

from trackworktime.

@mathisdt seems the issue is still there.

1. Don't track (to not trigger #25)
2. see weekly total, e.g. 44 min
3. reports: current, week, events tomes per task weekly
4. Preview
5. Preview shows 36 min

I had an example of past week where. The differences are
16:26 in app vs 15:24 in reports
5:24 in app vs 5:07 in reports

from trackworktime.