Or if you really want to be future proof, store the geolocation so you can try to figure out the jurisdiction for any changing regulations. Maybe they didn't change the date of the switch, but changed the timezone boundary on the map.

But, then I guess we might need to account for fractured societies and actually store some kind of organizational code for which belief system the event author adheres to? :-)

You jest, but there are three calendars in active daily use in close enough proximity to me that it is not unheard of for mistakes to happen. Especially in the evening, as not all calendars start the new day at the same hour!

To me that an UI/UX issue.

Internally everything is stored and handled in TAI (better than UTC as no discontinuity) and translated from/to something else for human consumption.

I.e. for instance your should have logic to figure out what TAI period corresponds to "next month's meetings" if that's what the user wants, which you apply immediately on user inputs and then forget about DST, time zones, etc. in the rest of the code and storage.

Another benefit is that if your user was in New York but is now in London it is trivial and well-constrained to adjust to local time.

No, it is not. It is because converting to UTC loses information that can't be retrieved.

Uh, no - meetings need to be stored with a timezone they were created in. This is how major calendar apps work.

In Apple Calendar you can enable advanced timezone settings and you get a timezone override option.