Scheduling Across Time Zones Without the 9 AM / 9 PM Problem

There is one typo that costs the most meeting time in modern remote work, and it is "AM" versus "PM." Someone in San Francisco proposes 9:00. Someone in Berlin reads 21:00. Everyone assumes they are on board. Then the calendar invite lands on a Tuesday morning that was supposed to be a Tuesday night — and the same meeting has rescheduled three times, because nobody is sure which 9:00 was real.

The time zone problem is different from every other scheduling annoyance. Availability questions ("who's free Thursday?") are simple to answer. Interpretation questions ("9 — your time, my time, or whose?") aren't. And interpretation is exactly the kind of job software should be taking off humans.

The problem

Scheduling across two cities requires one conversion. Across four or five — or across a distributed team where everyone is somewhere different — the organizer becomes a human UTC conversion engine:

• "9 AM my time" is ambiguous until you ask which time — and the reply thread where you find out has already lost half the attendees.
• Daylight saving is the silent killer. Twice a year one side shifts by an hour without announcing it, and your hand-computed offsets are now wrong by exactly the amount nobody notices on paper.
• Correct math doesn't survive the calendar. People write "3 PM ET" in an invite, then double-book their own 3 PM PT, because they typed the number that meant something to them that morning.
• And if any participant is external — a client, a vendor, a candidate — you've now asked a stranger to sign up for an account just to answer one question. Most don't. The meeting quietly dies in a thread.

The deeper issue: manual conversion is stateful. It depends on what the person remembered, where they were standing, and whether DST had kicked in yet.

Why it happens

It's not a tooling problem. It's a protocol problem. The de facto protocol for cross-time-zone scheduling is natural language: "How about Thursday at 9?" Natural language has no reference frame and no confirmation that a second human ran the same conversion.

A better protocol has three properties, and you use all three of them every time you book a flight:

1. Times are expressed relative to a known reference — like arrival times, always shown in the local timezone, DST rules baked in.
2. No one has to type anything that depends on memory.
3. Confirmation is explicit, so a misread is caught before the plane leaves, not after.

Scheduling has none of the three. You write "9" into an email and pray.

What good looks like

A cross-time-zone scheduler that respects that protocol works like this:

• Every time is shown in each participant's own timezone. The invite and the link both read "9:00 AM (your time)" — computed from the calendar's local rules, not from what you remembered the offset was.
• Slots are found against real free/busy, not guesses. The engine reads each connected calendar (Google Calendar, Microsoft 365, iCloud) and surfaces only the windows where every required participant is actually free. Nobody has to type availability in, and nobody converts anything.
• Recipients need no account. A client or candidate gets a link, sees the shortlist of candidate slots in their own timezone, and makes their choice. Nothing else is asked of them — and StitchLink works on free/busy status only, never event titles or details.
• Confirmation is one link. The chosen slot becomes the invite. Nobody re-enters it into another tool.

That's the whole feature. It's not exotic — just what a mature protocol looks like. But most tools still hand you raw numbers and ask you to do the conversion in your head.

How to put it into practice

Three habits eliminate most 9-AM/9-PM confusion even before you change tools:

1. Stop proposing raw numbers. Propose a window in a named reference. "Does 6 PM UTC–9 UTC work?" is unambiguous, and each person converts to their own time once, correctly.
2. Put everyone's local time on the first invite. "9 AM PT / 6 PM ET / 11 PM CET" in the invite description catches most misreads.
3. Treat cross-time-zone invites as one more confirmation round. "Confirming: Thursday, 9 AM Pacific — not 9 AM Eastern." It feels slow; the reschedule it prevents is slower.

The durable fix is to stop doing the conversion yourself at all. Give participants a link that shows times in their local time, let the engine do the UTC math and the free/busy math. The only human judgment left in the loop is the one that actually matters: which of the windows is best for the meeting as a whole.

Bottom line

The 9 AM / 9 PM problem is not an attention problem. It's the natural result of asking humans to run a stateful, DST-aware conversion pipeline in their heads, under time pressure. Any scheduler that still expects you to do that math — or to make a stranger sign up just to answer it — is asking for the reschedule, not the meeting.

Automatic scheduling across time zones should feel like booking a flight: times shown where you'll be, conversions done for you, confirmation in one click. Everything else is a thread.