Bug 236781

Created attachment 43356 [details]
Screenshot

What happened after deleting all times

A problem might be that I only have a symbolic link from ~/.kde/share/apps/ktimetracker/ktimetracker.ics to the actual place where I store the file...

I can confirm this bug, just hit me today. I can remember that I edited one or two times in the last days and today I saw those very high times also in my list. Fortunately I had a relatively fresh backup file...

I'm using KDE 4.4.5.

> A problem might be that I only have a symbolic link from
> ~/.kde/share/apps/ktimetracker/ktimetracker.ics to the actual place where I
> store the file...

I don't think that the symbolic link is the reason.

I can confirm this bug in another situation (though I'm still on KTimeTracker 4.3.3). When I move a subtask to the same or a new parent, the time values get incredibly high as Bodo reported for editing the task history.

My ICS file is also quite large (1.5 MiB).

After this bug happened, I looked at the ICS file and found that these high times got saved into the "X-KDE-ktimetracker-totalTaskTime" entries of VTODO items.

Also, I found a workaround how I can still re-parent tasks without running into this bug. I simply do it by editing the file in a text editor:
(1) Search for the name of the task that should become the new parent, and copy the UID: value from its VTODO entry, like "libkcal-398328694.938".
(2) Search for the name of the task to move, and change its "RELATED-TO:" value to the new parent's UID value that was copied before.

Now I updated to ktimetracker 4.4.5, and in this version (with the same ICS file I used before) this bug happens in the following two situations:

(1) Moving a subtask to another (or the same) parent task by drag and drop.
(2) Trying to edit or delete a record in the time history view.

The effect is always screwed time values for all or nearly all tasks, having 1.9 million hours as the largest total (up from 4000 hours normally).

This bug does not happen to me when starting fresh with an empty ICS file. So I presume it has to do something with peculiarities of this large ICS file I have. If somebody needs it to fix the bug, please e-mail me. I just don't want to post it here for privacy reasons.

At least with me, this issue happens only with files that were started with some previous version of ktimetracker (or before: karm) that handled storing times in the event history differently. It seems that some time ago, this application used "X-KDE-ktimetracker-duration:" entries in the iCal files to store event durations, resp. "X-KDE-karm-duration:" entries still earlier.

These entries are not evaluated by ktimetracker 4.4.5 any more; instead, it uses the difference between the VEVENT DTSTART and DTEND times as event duration. Now the problem seems to be that the early karm or ktimetracker versions did not save a DTEND value at all, and newer versions of ktimetracker supplement the current date for DTEND in such files when opening them for the first time. This results in VEVENT entries that might cover several years, and this produces the high amounts of hours reported in this bug.

So this seems to be not really a bug in ktimetracker (its calculation of total times from VEVENT times seems right) but an incompatibility with its old files.

This bug report mentions that these high amounts of hours appear only when trying to edit history entries or moving tasks. This is because such actions trigger a re-calculation of all task total times in ktimetracker, while in all other cases cached values are used for that (which are stored in "X-KDE-ktimetracker-totalTaskTime:" entries of VTODO entries in the iCal file).

Workaround

Of course it would be great to be able to correctly import old ktimetracker files, but as this bug does seemingly not appear with files created with version 4.4.5, a workaround might be enough. Here is what I did.

This workaround keeps your total task times, but removes the history (so you might lack some options for analysis after that).

The idea is to delete the full history and create just one new history entry for every task. The duration of this entry would be just as long as the aggregated duration of all previous history entries for that task.

Note that I edit the iCal file as text, as I find this more comfortable when having to edit many time values, when compared to the ktimetracker history window. But do as you like; if you use ktimetracker for that, you do not need step (3) below.

(1) Create a copy of your iCal file, and from now on, work only on this copy.

(2) Delete all VEVENT entries in the iCal file, using a text editor. They are all in a continuous section towards the end of the file. Take care to keep the last "END:VCALENDAR" line though.

(3) Open the iCal file in ktimetracker and ensure that all tasks have a unique name. If not (e.g. if subtasks of different tasks have the same name), this will complicate finding them in the iCal text file later. To fix this, for example prepend the name of the parent task followed by a colon and space.

(4) Create a VEVENT entry for every task / subtask that had aggregated task time in the original file. For that, simply let ktimetracker track some seconds of this task.

(5) Optionally: open the history window in ktimetracker ("File -> Edit History") and add a commment to all the new history events that you just created. I used a comment to indicate that these are special values for aggregating deleted history entries.

(5) Open the iCal file in a text editor and adapt the VEVENT entries to represent a duration that is the same as the aggregated duration from the old history. Search by unique task name to find the VEVENT entries, as they are not ordered in the file. You can set a special start time (like 2000-01-01 00:00:00) to indicate that these VEVENT entries are special ones, and to make adding durations simpler. 

If you use the ktimetracker history window instead for step 5, you can start a second ktimetracker as another user (like: "kdesu ktimetracker") to be able to read the task aggregation values from the original file while editing them with ktimetracker. Else, ktimetracker would not allow you to switch to a different tab while having the history window open.

In my case, I ended up with VEVENT entries like this (only the DTEND value has been adapted manually):

BEGIN:VEVENT
DTSTAMP:20100908T134628Z
COMMENT:aggregate entry for history before 2010-09-08
CREATED:20100908T125922Z
UID:libkcal-130800602.748
LAST-MODIFIED:20100908T134621Z
SUMMARY:Poject 21: (2) analysis and design
CATEGORIES:KTimeTracker
RELATED-TO:libkcal-1318910307.135
DTSTART;TZID=Europe/Berlin:20000101T000000
DTEND:20000101T211300Z
TRANSP:OPAQUE
END:VEVENT

To find out the correct values for DTEND, you need to convert the aggregate values as shown in your original ktimetracker file (before the bug got triggered) into days, hours and minutes. You can use Wolfram Alpha for that with input like "299 h 19 min":

http://www.wolframalpha.com/input/?i=299+h+18+min

It just happend again: I accidently made a task a subtask of another by "drag and drop". When I dragged it back to it's old position the times were screwed again.

As far as I can see this only concerns the calculated sum of the tasks in the ktimetracer.ics-File which are stored as X-KDE-ktimetracker-totalTaskTime: and X-KDE-ktimetracker-totalSessionTime:. You can even manually edit these values as you wish, Ktimetracker never ever recalculates them.

I do a dayly backup of ktimetracker.ics now. Does anyone know a way or tool to recalculate the total times from the Events?

@Bodo: ktimetracker recalculates the totals from the events in exactly those cases when this bug is triggered.

The problem is here that some events got screwed (far too long duration) because of file format incompatibilities, so the re-calculation produces wrong results. At least that was my result (see my analysis in #6 and #7).

I'd recommend you start with a fresh ktimetracker file (you'll never see this bug again then, I suppose); or if you want to take over the accumulated times, follow the workaround documented in #7 (that worked for me).

@Matthias: I compared two ics-Files: One before and one after the crash. The only difference were the calculated times (X-KDE-ktimetracker-totalTaskTime and
X-KDE-ktimetracker-totalSessionTime) as I wrote. The single tasks were not changed.

Additionally (as I wrote as well): When I change the calculated times in the ics file "by hand" and drag and drop the todos they are never re-calculated.

I started with a fresh ics-file a couple of months ago. The problem occurs anyway. I tried your workaround but I did not understand it and it was too complicated.

I had a similar problem a while back. I edited a specific time and suddenly there were more 200 hours than in reality. I eventually tracked down the problematic field. Somehow one of the earlier rows got its date changed when I edited another completely unrelated task. This didn't happen again since, but I can't risk my data to test it.

*** This bug has been confirmed by popular vote. ***

Another way to reproduce: Just editing times can screw the total. The old total was about 15 hours, after adding 1h 30min to a task the total was over 75 hours.

(In reply to comment #13)
> Another way to reproduce: Just editing times can screw the total. The old total
> was about 15 hours, after adding 1h 30min to a task the total was over 75
> hours.

Sorry, ignore my comment #13 please

Created attachment 56139 [details]
timer file before editing

Comment on attachment 56139 [details]
timer file before editing

This problem occurs when editing even for a timetracker file created with 4.4.5.

I created a new timer file with a single task. I started the timer and let it run for about 5 minutes. The export of times contained expected values. I then edited the task to start about 5 minutes earlier than actual. The next export reported a time of -4.5 hours for the task.  Note that changing the ending time seems to work OK.

I would like to attach the file from after the editing but this form seems to only allow one attachment.

Created attachment 56140 [details]
timer file after editing start time

*** This bug has been marked as a duplicate of bug 188769 ***