I believe this is not correct for future scheduled events for humans. When a human sets an event for 8AM on some day 3 years in the future (maybe through a recurring weekly event), what they mean is "8AM local time in that jurisdiction". When a law passes that changes the daylight saving time amount or DST switch date or just sets the timezone to be different or the jurisdiction is merged into another or whatever, humans expect future scheduled events to adjust accordingly. Imagine a clock tower in the town square. If something political happens, it will be adjusted, and a meeting set to 8AM local time should occur according to that (possibly virtual) clock tower clock.

That is why logs (moment of time in the past) should be stored in UTC (possibly with local or user's timezone name for UI), timers (short offsets into the future from a moment of time in the past) should be stored in UTC like logs, and future scheduled events between humans should be stored in local time with the name of the timezone. The name of a timezone is never the offset, it is always the jurisdiction that can change the rules and be merged into another, etc.

When answering the question "what is the UTC time of a future scheduled appointment?", which is equivalent to "does it intersect a future scheduled appointment set in a different timezone on the same or adjacent dates?", which is also equivalent to the question "how many seconds in the future is this from right now?", you must assume the timezone rules set by politicians will not change between now and the appointment time. If the appointment time is soon (e.g. under 3 months), you indeed can assume this, because legislating an unexpected timezone change that will take effect "soon" is stupid and will usually not be done. But for a scheduled appointment a year from now? You honestly don't know. You can guess, but you must assume this can change by a TZ database update and act accordingly. If you have converted from localtime to UTC when the appointment was created, it is difficult to adjust correctly when TZ db is updated. If you translate to UTC only "just in time" when rendering or detecting collisions, everything will work correctly.