If priorities are being made after code is written then it won't matter if the code took a day, a week or a month, or whether it was done under the company's florescents or a sunny back patio. Decisions about near-term objectives should be made before work is underway, or interleaved with experiment development and analysis.

Your last statement actually supports my point that it shouldn't be about hours served but about objectives met.

Admittedly, it is much more difficult to clearly define work expectations when they aren't in terms of hours, and doing so fairly across team members is especially difficult. And things like on-call rotations complicate that even further. But it's also very easy to game a system that is hourly-based and often results in schedules slipping, or worse: some team members doing heroic efforts near deadlines to make up for other team members that think they've done their work because their timesheet said so.