Created attachment 125368 [details] Time data before moving a subtask at a completely different position in task hierarchy SUMMARY Changing the hierarchy of tasks scrambles time data of all tasks. STEPS TO REPRODUCE 1. Move a subtask to another higher-order (sub)task OBSERVED RESULT Time data is scrambled, s. attachments. The task shown in the screenshots remained completely untouched. A new task was created with several subtasks with additional subtasks. As soon as one of those subtasks was moved to another position in the hierarchy of this new task, time data of all tasks went nuts - like the one shown in before.png/after.png. EXPECTED RESULT Time data does not change. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.0
Created attachment 125369 [details] Time data after an independent subtask has been moved in task hierarchy
I wasn't able to reproduce when starting an .ics from scratch with a recent version of KTimeTracker. The problem might be limited to working with .ics files created in previous versions of the app. Andreas, which version of KTimeTracker did you use to create the initial version of your .ics file? The screenshot mentions dates back to 2019-02-01, does this imply you used KTimeTracker 4.14.10 back then? Note for my future self: install KTimeTracker 4.x and produce some sample .ics files for later compatibility testing.
(In reply to Alexander Potashev from comment #2) > Andreas, which version of KTimeTracker did you use to create the initial > version of your .ics file? I use ktimetracker continuously since the days it had been called karm. So I guess that initially I used a version that was based on flat files … Through the years the file format was converted several times. I can't tell anymore if this always happened on-the-fly or sometimes by importing the current file containing data in an outdated format. > The screenshot mentions dates back to 2019-02-01, does this imply you used > KTimeTracker 4.14.10 back then? "grep DTSTART ktimetracker.ics | sort" tells me, that the oldest regular entries in my current ktimetracker.ics date back to May 2013. Though there are some irregular entries, too: DTSTART:19800406T010000 DTSTART:19800928T030000 DTSTART:19810329T020000 DTSTART:19971026T030000 DTSTART;TZID=Europe/Berlin:20130529T160247 The first four entries of the list don't share the format of the others (timezone data) and point to a date I am sure ;) not to have used karm/ktimetracker. Additionally there are some tasks that are older, me knowing the work was done e. g. in 2011, but they seem to have lost their history. "Total Time" is available and valid but there is no information how "Total Time" gained its value. I can try to anonymize my file and send it to you for testing.
(In reply to Andreas Kilgus from comment #3) > (In reply to Alexander Potashev from comment #2) > > "grep DTSTART ktimetracker.ics | sort" tells me, that the oldest regular > entries in my current ktimetracker.ics date back to May 2013. Though there > are some irregular entries, too: > > DTSTART:19800406T010000 > DTSTART:19800928T030000 > DTSTART:19810329T020000 > DTSTART:19971026T030000 Meanwhile I recognized that these do not belong to VTODO or VEVENT sections, so there's nothing wrong here probably. > I can try to anonymize my file and send it to you for testing. Unfortunately my email seems not to have reached you. Anyway, another observation: While ktimetracker is running, a lot of entries 'm_sessionStartTime= ""' appear in my system log. The time interval between the groups of these messages seems to correlate with the autosave interval. I cloned your git, extended the contents of the debug message and tried to compile the code to see if I can identify the tasks in ktimetracker that cause these messages. But I already failed at compilation stage. Even after a bunch of additions to the CMakeLists.txt I did not manage to get a working Makefile so I gave up eventually. If you can provide some explanation how the code is supposed to be compiled, I'll give it another try.
This just happened to me. Before I had times logged such as 8 hours something.. 10 hours something. Somehow, moving a new task from the lowest hierarchy down into another hierarchy added hours of time to most of the tasks, but not all of them. For some tasks it looks like a decimal shift. Like 8 hours 25 min in the time reference frame would become 82:50 in the decimal system which is now interpreted as having worked 82 hours. I only started to use this software two weeks ago but basically it ruined all my times, I think with these kind of bugs I'll head to another tool :( KTimeTracker Version 4.14.10 Using KDE Development Platform 4.14.38 OS: Linux (x86_64) release 4.15.0-154-generic
Re: comment #4 Please find compilation instructions at https://community.kde.org/KTimeTracker#How_to_build Thanks for the .ics file you shared in a private email! I was able to reproduce the bug, it should be enough for me to track down the root cause.
(In reply to Alexander Potashev from comment #6) > Re: comment #4 > > Please find compilation instructions at > https://community.kde.org/KTimeTracker#How_to_build Thanks. I already had seen them but had tried to compile from a source rpm. Cloned the git repo and this way compilation succeeded.