An alternative would be to describe potential break-points and conditionals in the planning process. For instance, if a third party library can help you with some core functionality, it takes a few hours to investigate and an hour to implement.
But if it's not going to work for whatever reason, then you know you have to make your own, and the initial implementation could range from 4-6 weeks.
If you say "this will take either 4 hours or 4-6 weeks", that's far more useful and acceptable to management than saying "this will take somewhere between 4 hours and 6 weeks.
No one sane is asking for exact estimates, and no one smart is promising a hard deadline based on the assumption that nothing goes wrong. A good engineer will pad their estimate slightly for the same reason that airplanes carry more fuel than the exact amount they need to reach their destination. It's not a deceptive or inefficient practice, it's managing uncertainty.