20081204

The problem with measuring elapsed time on a laptop

Someone pointed out Rachota Timetracker to me the other day, probably yet another hint that I should try and do my timesheets on time. It probably came from Elijah Alcantara's comment on this digg.

My requirement is that I need a quick way to record what I am doing, but I am not always connected to the web (although I am about 90% now). A typical day is open laptop at home, slap lid down go to office, move offline to meeting room, back to office, get on train to client site, open laptop in meeting, slap lid down and head home, open and catch up in evening. The laptop gets rebooted on average twice a week.

The problem I have is that the tools for measuring time, and reacting to it, tend to go wrong when my laptop hibernates/sleeps between usage. Lightning calendar is a classic example, alarms work fine from startup to first sleep but after that the drift causes alarms to go off at the wrong time, I could use a web based calendar as that would not suffer, but I am not always connected and when I do connect it can be too late.

I was hoping that Rachota would have sorted this out, but no, sadly. I have to remember to 'relax' before slapping the lid down and running.

There are a number of possible solutions but the best one I have found in my own work as been to 'observe the system clock'. The principal is that you sample the system clock at known intervals and note the difference between the system clock delta and the interval period, assuming normal operation the minor drift that you get should average out to 0 over time (using the right kind of timer). When the computer hibernates/sleeps or you get a DST changover then you might get a difference of +1 hour for example (depending if you read localtime or UTC). That way if I start a task at 12:00 and hibernate at 12:15 for 30 minutes, when I reawaken the process and Rachota would have said 45 minutes elapsed, I know that by observing a +30 minute shift I should take 30 minutes off. If someone was messing about with the system clock then they can move it back and forth as much as they like and the technique should keep up subject to the granularity of the time interval (which will vary depending on the timing accuracy required). The system clock observer would fire off TimeShiftEvents to elapsed time listeners that would be registered and deregistered as they start and stop.

I know there are scenarios where you want to measure that off time, but you could easily make that an option for the user.

I would do the change myself but I just can't stand netbeans based projects. ;-)
Blogged with the Flock Browser

3 comments:

Jiri Kovalsky said...

Hello Straun,

my name is Jiri Kovalsky and I am author of Rachota Timetracker. Thanks for your blog post about my application!

I consider your idea as interesting and Rachota actually samples system clock just like this every second. You are right that if the interval is longer than usually it is simply added to current task. What is your suggestion in such case? Should Rachota ask user what to do if the last check was for example more than 10 minutes ago?

Finally, why don't you like NetBeans projects? It's just a folder with predefined structure for sources, tests, built classes plus 1 NetBeans configuration directory. It builds itself with Ant. Can you please elaborate this? You know, I am NetBeans Technical Community Manager ... :-)

Thanks a lot for your answers!

Best regards,
-Jirka

straun said...

Jiri,

Thanks for the reply, I am pleased that you have already identified the issue and implemented the main step, which is allowing for it.

My suggestion would be:

Some tasks are only relevant when you are using the computer and others can continue when the laptop is closed. So I would ask the user which type of task it was/is.

I think you should record both 'active' and 'sleep' versions of the elapsed time. At report time if the task is computer bound, e.g. 'data entry' then you report the active time only, otherwise you report the active+sleep time.

Allowing the user to see the difference between the 2 is the key thing. They are then empowered to account for the right amount of time to the task.

Regarding NetBeans, my aversion comes from other open source projects I have attempted to get 'into' and been forced to veer too far from my preferred development environment, which takes a lot of the fun out of it. After my 3rd such experience of having to completely change my tooling just to get it to build I stopped joining those projects. I am sure yours is much better organised.

I have some more suggestions regarding non-contiguous working hours etc.

Good luck with the tool (I am still using it which is a good sign).

Straun

Jiri Kovalsky said...

Hi Straun,

are you still using Rachota? If not, I suggest you check out the latest development build of Rachota 2.3 [1] which already contains the hibernation support you required. The solution I have implemented is based on your ideas:

* delayed clock tick detection, in case of significant delta ask user or do predefined action automatically
* according to user preference: ignore delta & stop measuring current task or add delta & continue measuring current task or don't add delta but ask user what to do
* default hibernation threshold set to 10 minutes + default action set to ask user - both configurable in system settings

[1] https://sourceforge.net/projects/rachota/files/Rachota%202.3/rachota_23.jar/download

Let me know what you think about it!

Best regards,
-Jirka

P.S. I also recommend trying out NetBeans 6.8 - our latest release. :-)