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.

1. Recurring meeting events have to take place in a certain zone so that the right epoch time can be calculated for the recurrences across DSTs

2. Even single meetings need them (see other post in this thread)

3. You may need other zone's local times. Imagine you're scheduling shifts for people to work. If you're in a different zone than work is scheduled in, the presentation later needs to know that zone to compute the right epoch times.

Year 2038 problem: https://en.wikipedia.org/wiki/Year_2038_problem