This is exactly the wrong approach for calendaring software, because it results in appointments moving in time when governments change the daylight saving time rules.
Storing in a local time (plus time zone) is exactly right for calendaring. And the correct-sounding, but wrong, mantra of "always store in UTC" is why calendaring apps handled the change so poorly.
How do you handle future timestamps when time zone data changes? Update all future timestamps? Keep a separate timestamp recording the timestamp at which the future timestamp was last updated?
Storing timestamps at UTC solves this at the expense of knowing how to view the timestamp at a specific time zone.
If the timestamp is defined in local time (e.g. "a meeting is scheduled for 15:00 every second thursday") and you generate a list of the next events as UTC, and then the DST rules change, you have to go in and fix all the UTC timestamps for future events.
If you store local time + timezone name, the stored time doesn't have to change, and if you need it in UTC for display you can calculate it on the fly, using the most recent rules you know.
If intervals are more important (e.g. do something every 30 minutes, or exactly every 24 hours), then UTC is better, or if you are recording events as they happen.