If you schedule a meeting in the future you typically agree on a local time in a specific timezone. So the (local time, timezone) tuple is the authoritative value you want to store (you can cache the utc time if you want).
Just storing the utc time and timezone is problematic, since the conversion function between utc and local can change via tz database updates, sometimes with little notice (Israel is notorious for sometimes only deciding on the DST switching date shortly before it happens).
In principle you could store (utc-time, offset used to convert from local, timezone), but I find that rather unintuitive and error prone, since it doesn't cleanly separate authoritative from cached values.
Just storing the utc time and timezone is problematic, since the conversion function between utc and local can change via tz database updates, sometimes with little notice (Israel is notorious for sometimes only deciding on the DST switching date shortly before it happens).
In principle you could store (utc-time, offset used to convert from local, timezone), but I find that rather unintuitive and error prone, since it doesn't cleanly separate authoritative from cached values.