Time Zone Issues

Mozilla is an international project. So why are most or all of our big meetings defined in the US Pacific timezone[0]?

tl;dr: originally for historical reasons, and now because the other alternatives are worse. Use http://arewemeetingyet.com/ to ease the pain.

Explanation

There are two possible timezone policies you could have for scheduling cross-project meetings:

1. define all times in the same particular timezone; or
2. define all times in UTC.

Any policy other than these two is clearly worse, because if some meetings are defined in a DST-using timezone and some are in UTC, the clock shifts brought by Daylight Savings will mean that every six months, some meetings move and some don't, and meetings start to clash. If all meetings are defined in the same timezone (either a particular region or UTC), then you avoid this problem.

So why not switch to UTC for everything?

For the reason given above, this would have to be a project-wide change, mandated from the top, to avoid us falling into the clearly-worse situation of half the meetings being UTC and the other half being Pacific. So let's say we did that. What would happen?

Firstly, it would be a massive change. Everyone would have to update their personal calendars for every meeting. Some calendars, amazingly, don't support defining meetings in UTC (the workaround for Google Calendar is to place your meeting in e.g. Rekjavik). But once we were all done, some things would be worse.

Firstly, meetings would change wallclock time every six months in DST-using countries, including the US and EU. So instead of a meeting being (almost) always at 11am, it would be at 11am from October to March, and 10am from March to October. A lot of Mozillians are in northern hemisphere DST-using areas; this doesn't seem like it would increase the likelihood of them making their meetings on time.

There's one particular case of this which leads to a particularly bad problem. A lot of Mozilla meetings involve interactions between the US and Europe. And there's a key hour for that - the one beginning at 9am Pacific Time (5pm UK time, 6pm Central European Time) where everyone is awake and working. A lot of meetings get put in this slot.

Because both the US and the EU use Daylight Savings Time, if meetings were defined in UTC, then the actual scheduled time of the meeting, as defined, would need to be changed every six months to keep it in that key slot. That would require reissuing invitations, calendar updates and administrative hassle, all to achieve the effect you get for free by defining the meeting in Pacific time anyway. This doesn't seem like a good scenario.

Not everything would be totally worse; if we used UTC, the poor guys in the southern hemisphere, whose Daylight Savings moves the opposite direction to everyone else, would only have one hour swings in their meeting times instead of 2 hour swings. We love them dearly, but there aren't nearly as many of them as there are people in the northern hemisphere. And they're used to it :-)

But isn't there symbolic value in using UTC? We are a global organization...

The current arrangements seem to be the least worst option for actually getting work done. Do people really judge our value as an organization on whether we use UTC?

So even if we fix them in Pacific, can't we use UTC in meeting announcements?

There are two use cases for a meeting announcement - "what's the time of the (next) meeting in my timezone?", and "what do I put in my calendar to make sure it gets it right for all future meetings?". UTC is the answer to neither of these questions. Unless you live in Rekjavik.

So how can I help people understand when a meeting is happening?

Use the excellent http://arewemeetingyet.com/, which provides the time of the meeting to meet both of the use cases above.

[0] Yes, not all meetings at Mozilla are defined in Pacific time, but most of the large cross-project, cross-timezone ones are.