[tallanvor]

What if you're scheduling a meeting for multiple people, and normally you're in Seattle, but for some of these meetings you'll be in New York? You don't want the meeting to be at 8:00 your time because chances are the people in Seattle aren't going to join your call at 5:00 their time.

[ubermonkey]

As someone who routinely sets meetings for people in multiple timezones, let me say this isn't confusing.

All the calendaring tools I use or am aware of, at this point, keep up with time zone correctly (or have so far). I set the meeting for, say, 10 CST, and it's clear to my colleagues in Seattle that it will be 8 for them, just as it's clear for my coworkers in DC that it'll be 11.

[kevincox]

There are still edge cases.

What if you schedule a meeting in a year's time in a timezone that doesn't have Daylight Savings Time but that government decides to add it and now the meeting is at a time that doesn't exist?

But your use case it also talking about when using a tool that is specifically designed to deal with this issue. What about when you are trying to find a good time (AFAIK most calendars don't have good tooling for collaboratively choosing a meeting time). If you do this in your favourite chat app then you probably have no timezone support. (This would be an awesome feature though)

[Schiendelman]

Real calendar applications handle this by storing the scheduled time as GMT, and the UI adds an offset for where users are. This also solves the problem of you driving between time zones between the time that you schedule the meeting and the time that you attend it.

[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.

[bslorence]

Twice a year we have to deal with calendar screw-ups because a third of our employees are in a locale that doesn't observe DST and the rest are in locales that do observe it. If an employee from that first group sets up a recurring meeting, the meeting time changes for everyone else in March and November.

[detaro]

A meetings timezone can be independent of a users, yes. E.g. the meeting time should be specified as e.g. "8:00 America/Los_Angeles" (or have a location-based lookup, but thats another level of indirection). That way it follows whatever DST rules there are, but your local phone time being in NY time only affects your display.