UTC is generally a good idea for storing, but there are still some ways to have that bite you. If a user enters a local date time for a future event in a particular time zone, converting that to UTC could result in incorrect behavior if the timezone definition changes. It depends on if the user meant that UTC time or if they meant the local time.
It can also cause trouble if you store past events but do not store the user's local offset or timezone at the time of the event. If you aggregate these events later into a dataset of "events by hour", they may be grouped wrong (from a user's perspective) if you convert them all to the user's _current_ timezone.
You need to be careful with some circumstances. I recently had to fix up a case where someone had tried this with a recurring local date. Something needed to happen at 4am local time every day. They had converted 4am local time to UTC based on the timezone offset on the day the config was saved. This then restored incorrectly when the timezone offset changed because e.g. a DST transition.
Well, I guess I should have written in the OP, that I do both conversions at the time of the query. It's useless to try storing the UTC. It needs to be JIT.
I convert the target TZ to UTC, using my local utility, then use my local TZ utility to convert from UTC to local.
But I write iOS software, so I have very solid local tools at hand. It might be more problematic, on, say, a webserver.
On a related note, I wrote this utility[0], some time ago. It uses the TZ map from the TZ Boundary Builder project[1].
[0] https://github.com/LittleGreenViper/LGV_TZ_Lookup
[1] https://github.com/evansiroky/timezone-boundary-builder