The way nearly every team I have ever been a part of has handled this is that bugs are triaged regularly by some subset of the product team - usually dev lead, QA lead and PM lead. The triage team is responsible for deciding whether the bug meets the bar to be fixed and assigning it to the appropriate team member for fixing. During triage a bug can be assigned to a a few different traige states:
It should be put into the Investigate state if more information is needed in order to determine whether it should be accepted or rejected. If it is accepted, that should mean that the triage team already has a fairly good idea how big of a work item it is and the availability of the team member it is assigned to.
Any time spent investigating and/or fixing and/or unit testing a bug that has already been accepted is considered time spent fixing the bug. There is no need to break it down beyond that for any purpose that I can think of. Even tracking exactly how long it takes to fix a bug doesn't feel like very actionable data. The only time I can think that it would come into play is if the triage team thought a bug was a quick fix and it ends up being much more complex and then it's just a matter of talking with the developer (hopefully in daily standups) to understand how long it should take to fix. Still, this would be on a more case by case basis for managing a release and less useful when thought of in terms of trending data used to make future business decisions.
Why do you need to know how old defects are and whether they are being worked on? Is this to make sure that you're on track for a release? It seems like a much more direct approach would be to have a discussion with each developer about what they are working on and what they expect to finish prior to the next milestone. This is a great value you get out of daily standups.