My experience with time estimates is that they generally do not work well. Estimating complexity (as in story points) works to a certain degree, but it's only a very rough measure. Time estimates can work when the project scope and/or budget is flexible. Then you have a chance to make ends meet within the time estimate you provided, but I'd consider that not being within the scope of your question.
In my experience, the desire for a time estimate often stems from an underlying desire for control (mostly over a budget). That desire is understandable. As an example, if you put yourself in the shoes of a customer wanting your car repaired, you will most likely have a strong desire to know what it will cost before the actual repair is carried out. That desire is justified for a number of reasons, the most important one being that you need a basis for a decision for or against the repair. It wouldn't make much sense to invest more than the car is worth, for instance.
Now, it's not always possible to state a price, especially if what you're building (or repairing) is subject to uncertainty. In that case, I'd recommend that you provide your customer (or boss or investor) with another measure of control. In agile development, the easiest thing you can do is shorten your cycles and give them full transparency over your progress and the ability to stop or change direction at each product increment. This would be analogous to the repair shop offering you a phone call after they got a better diagnosis of the problem for which you paid only a small amount and then you get the chance to decide again, maybe with a better estimate of the overall repair cost.