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