Scheduling across time zones without losing anyone to the maths

A meeting across three time zones is the same decision as a meeting across one — everyone has hours they can and can't do, and you are looking for the overlap. What changes is that every person now sees the same hour under a different name, and the tool in the middle either translates faithfully or quietly makes one person's Tuesday evening into another's Wednesday morning.

Most of the failures are not exotic. They are the same three mistakes, made over and over.

Mistake one: the organiser converts by hand

The host writes "3pm my time, so that's 5pm for you and 10pm for Priya", and one of those is wrong. Not because the host is careless, but because doing this for eight people across a date range is a hundred small calculations, and one of them will be off by an hour on the day a clock changed somewhere.

The fix is that nobody converts by hand, ever. The tool draws the grid in the room's own zone, and each participant flips it to theirs with one control. What they paint is what they mean; what the host sees is the same painting, read back in the host's clock.

Mistake two: averaging the day away

A room spanning Lisbon and Bali has an eight-hour offset. A "good" slot for the group, if you score it as an average across people, is one where the Lisbon people are mildly inconvenienced and the Bali people are mildly inconvenienced. That sounds fair and is useless: nobody is at their best, and the person for whom "mildly" means 11pm will stop coming.

The better rule is the one every Compromise meeting room uses: a person's score for a candidate time is their lowest level across it, never the average, and the group's score for that time is built from those minimums. A slot that is ideal for Lisbon and not free for Bali is simply not a candidate. Attending most of a meeting is not attending it, and an 11pm slot someone marked "would rather not" is honestly reported as exactly that, next to their name, rather than averaged into a number that looks fine.

Mistake three: daylight saving

This is the one that breaks tools silently. Two cities that are two hours apart in March may be one hour apart in April, because one of them moved its clocks and the other didn't. A grid that stores availability as instants — 14:00 UTC on such-and-such a date — and displays them in local time will show a person's painted "every Tuesday at three" drifting to four for half the year.

The design that avoids it is a little counterintuitive: store the grid in wall-clock time in the room's own zone, and never store instants at all. "Tuesday, 15:00–16:00, room time" is the same cell on every Tuesday, by construction, whatever any clock did. Conversion to a participant's zone is done when the grid is displayed, cell by cell, in their browser, using their own system's knowledge of both zones — and because the room's day may contain a clock change inside it, the conversion is worked out piecewise rather than as one offset per day.

That is how a Compromise meeting room stores availability. The backend never resolves a time zone; it holds the zone's name as an opaque label and every conversion happens on the participant's own device. It is slightly harder to build and a great deal harder to get wrong.

What the participant sees

If the host turned on participant time zones, the answer page shows a zone switch. The grid is labelled in the participant's own zone — including when a day starts and ends, which may not be midnight for them — and the availability they paint is stored against the room's cells. They never see a UTC time, and they never see the host's time unless they ask for it.

If the host left the setting off, nothing converts: everyone reads the room's own clock, and every label is exactly what it would have been before time zones were a feature. That is the right default for a group in one city and the wrong one for a group across three, which is why it is a switch.

What the host sees

The results page is in the room's zone, with the same switch to read it in any other. The best time, the alternatives and the heatmap all move together — there is never a case where the headline is in one zone and the heatmap in another — and the shortlist is thinned so the offered times do not overlap, whichever clock you read them in.

When the host closes the room, the chosen interval is frozen in room time. A participant in another zone who opens the link later sees it in theirs, correctly, even if a clock has changed since.

Setting one up

Create a meeting room, pick the room's zone — usually the host's — and the date range and daily hours in play. Turn on Let people answer in their own time zone. Send the link. Each person paints in their own clock, alone, and the overlap falls out without anyone opening a converter.

For a group that meets on a schedule, the same room can be a series — it re-opens itself every week or month, and the zones come along with it.