However, it's recently been suggested that management might begin to use this timesheet data for other purposes
This is often a concern when a system is introduced, but in my experience its never been the case. My staff and I currently fill in timesheets, in the catergories you mention, in roughly 15/30 minute chunks. The aim for us is to better gauge how much effort is put into a project, so that further down the line when we have a feel for how much time is spent in all the areas, we can better estimate how long similar projects are going to take. It saves us from trying to meet ridculous deadlines.
Timesheets should never be used for "assessing individual programmer productivity and performance" as there can be all sorts of factors that are out of the control of any one programmer. What if requirements were poorly defined, and they've had to go back and rework chunks of code, is that the programmers fault? Anyone who uses simple time based metrics to gauge performance is either a bad manager or they are not the company you want to work for.
As for measuring/recording time spent working in your own time or coming up with new ideas, this can be a difficult one. I personally don't, even though I do it most of the time. As do all my staff. However, it is one thing that I do look favourably on when appraisals come up. And perhaps I should mention I've never used timesheets in an appraisal, except to remember all the projects that someone worked on. Then I am more interested in how well they performed not how long each project took.
Barbie | Birmingham Perl Mongers user group | http://birmingham.pm.org/