[kevincox]

The problem is that the GMT time for a future event is unknowable. Timezones change based on the whims of governments. They change rarely, but they do change.

Your calendar can store the GMT time for lookups but it will need to recalculate this if the timezone data changes.

Furthermore it isn't as simple as "storing GMT" for repeating events. As the offset will be different for different occurrences. So you need to store the original timezone for the recurrence rule. (And see the above problem about the absolute time of a current local time being unknowable)

[Schiendelman]

As far as I’m aware, GMT has never changed since the advent of computing.

Yes, you do need to store the location of the scheduler so that you can adjust everything as appropriate, and of course you need to schedule the time the event was created. But you still only store those times in GMT.

By the way, what I’m describing is the way every AWS system does it.

Edit : Oddly, I can’t reply to your reply to this, but I already addressed the case you were talking about in this comment.

[kevincox]

The problem isn't that GMT changes, it is that the local time changes.

If I schedule an event in 1 year at 08:00 in MyCityTimezone and you store that the event occurs at 13:00 GMT then 3 months later MyCity decides that they aren't doing Daylight Savings Anymore your GMT time is now wrong. My event must still occur at 08:00 which is now 14:00 (or whatever) GMT.

"Just" storing it in GMT isn't enough. You probably do want to do that but you need to store the local time as well and update GMT to match if timezones change.

This is very frequently done wrong because timezones don't change often so the "Just store GMT" mostly works. But if you are writing a high quality system you need to deal with these cases.