Adding on to @ndaidong's answer:
It's incredibly difficult and most often inaccurate to estimate using time. There are so many variables that might be unforeseen/unknown (System downtime, another necessary person may be unavailable, conditions of satisfaction that aren't declared and are unmet) that I've found time estimates to be a very poor measure of estimating. There isn't a developer I know that doesn't, AT LEAST, double the estimate they give (others will even triple or quadruple theirs).
The method I advocate is the Agile method of using difficulty points. This allows you to focus less on how much time you have left and GSD.
Assigning difficulty points to a task will allow you to, over time, show an average estimated time of completion for a task of a given difficulty. For example, you might spend an average of four (4) hours on an 8-point task. This allows those viewing your tasks to see that if you give 8-points to another task, it should take around 4-hours, without committing to it. The business gets what they want (measurable results) and you get to avoid (inevitably) disappointing them with a low estimate or irritating them by always estimating far and above the actual time to completion.
Let the points speak on your behalf.