Sure, but now you've reduced the scope of the problem to a few edge cases. Every other solution I've seen still has these edge cases and doesn't solve the core problem as simply as UTC. If you think otherwise, can you describe or provide a link to these other solutions?
For region-specific events (which includes most physical meetings, by convention many financial processes etc.), it's much safer to store both the local time and time zone city, as well as the UTC offset at the time of writing, and to convert to UTC only at runtime using an up-to-date time zone database.
That way, you can identify all of:
- Future timestamps you might want to re-process, e.g. for notification scheduling, because the future UTC conversion has changed between scheduling/updating the event and now.
- Equivalently, timestamps written by software/an OS running an outdated TZ database. You should talk to them; things are about to go wrong if the date is in the non-too-far future!
- Trivially and without conversion, the local time that people will use in the meeting notes, documenting that you missed the meeting because you didn't update your TZ database and dialed in to the meeting an hour late
