You cannot determine the size, but you can estimate it. An estimate gives some information to your manager, and therefore it delivers some value. This is better than no value, therefore you should take the trouble to make an estimation even if it won't be exact.
Why is this so? Because a business runs on repetition. Sure, telling your manager that making a fix has a 50% chance of taking less than a day is not hard information. But your manager has more than one report, an there is more than one day in a project. If your estimates are good, in the long run half of these issues will take less than a day, and this is a valuable thing to know when budgeting, planning, etc.
And how do you estimate? Well, you compare to the closest previous situations, and you guess. That's pretty much all there's to it. Obviously it takes some expertise to judge which situations are similar, and you'll sometimes get it wrong. That is not the point. The point is that no matter how inscrutable a problem seems to you, you, as the developer, have a better chance of making this judgement call than your higher-ups, therefore you are the logical person to make that call.
This is no different from an MBA hiring a programmer to program for him because he's better at programming: you get paid to perform a valuable service - in this case, reducing planning uncertainty for the project you're working on. It doesn't matter that you can't reduce it to zero - in business you have to think in marginal values, not absolute ones.