Core Hours for a Team Across Four Time Zones

Before you write a core hours policy, do the arithmetic. A team spread across four time zones from Central Europe to the US west coast has, on a standard nine-to-five, no overlap at all — not a narrow window, none — and the policy you are able to write is decided entirely by that number rather than by what you would prefer. Teams skip the arithmetic, announce core hours of 10:00 to 15:00 in a time zone nobody names, and find out in week two that it means 06:00 for one person and 22:00 for another.

The arithmetic takes about ten minutes. It is the only part of this that is not negotiable, because everything downstream — whether you can have core hours, how wide they are, who pays for them — falls out of it.

Do the overlap arithmetic first

Convert everybody to UTC and intersect. Not approximately, in a shared doc, with the actual numbers.

1. For each person, write their genuine working window in local time. Genuine, not contractual: if someone does the school run and starts at 09:30, the window starts at 09:30.
2. Convert each window to UTC.
3. The overlap starts at the latest start time and ends at the earliest end time.
4. If the latest start is after the earliest end, the overlap is zero. This is a normal result and most teams who announce core hours have never calculated it.

Here is a four-zone team on a 09:00–17:00 local day, during European summer time — Berlin at UTC+2, London at UTC+1, New York at UTC−4, San Francisco at UTC−7:

Latest start: 16:00 UTC. Earliest end: 15:00 UTC. The overlap is negative. There is no hour of the working day when all four people are at their desks, and no policy wording changes that.

Drop San Francisco and the same team has 13:00–15:00 UTC — two hours, which is 15:00–17:00 in Berlin, 14:00–16:00 in London and 09:00–11:00 in New York. That is a workable core hours policy. The fourth zone is what destroyed it, and the honest version of this post says so before it says anything else.

What it costs to manufacture an overlap

You can create one. You do it by moving somebody’s window, and somebody is then paying for the policy personally.

If Berlin moves to 10:00–18:00 and San Francisco to 08:00–16:00, the intersection becomes 15:00–16:00 UTC. One hour. In local terms that hour is 17:00–18:00 for Berlin, 16:00–17:00 for London, 11:00–12:00 for New York and 08:00–09:00 for San Francisco.

Note who absorbed it. The Berlin person gave up the end of their day, permanently, and the San Francisco person starts every morning in a meeting. New York and London gave up nothing. That asymmetry is the actual content of the policy, and it will be the reason somebody quietly stops attending in month four. Write it down. A policy that names its cost survives a conversation about fairness; one that pretends the hour came from nowhere does not.

If you cannot find someone willing to carry that hour, you do not have core hours. Skip to the last section.

Pick one of the three things core hours can mean

Most policies fail here rather than at the arithmetic. “Core hours” is used for three different promises and teams write one while enforcing another.

• An availability window. You are reachable and will answer within the window. You are not necessarily free.
• A meeting window. Synchronous meetings may only be scheduled inside it. Outside it, nobody may book you.
• A response window. Messages sent in the window get an answer the same day. Says nothing about meetings.

These have different failure modes and different enforcement. An availability window gets eaten by meetings, because availability is what a booking tool reads as free. A meeting window is the one worth having on a four-zone team, because it is the only one that protects the other twenty-two hours. A response window is weaker but is the only one that works when the overlap is zero.

Choose one, name it, and do not use the phrase “core hours” for the other two.

The written core hours policy

Short enough that a new starter reads all of it. This is the meeting-window version, which is the one to default to.

Core hours: 15:00–16:00 UTC, Monday to Thursday.

What it means. Recurring and cross-time-zone meetings are scheduled only inside this hour. Outside it, nobody schedules a meeting with someone in another region without asking them first, in writing, in advance.

What it does not mean. It is not an availability guarantee and not a response-time commitment. It does not mean the hour is reserved — if nothing is booked, the hour is yours.

Who is paying for it. Berlin works 10:00–18:00 local and London 10:00–18:00 local to make this hour exist. San Francisco starts at 08:00 local. This is reviewed every quarter and the burden rotates if anyone asks.

Exceptions, decided in advance. Incidents. Anything with an external customer on it. The weekly all-hands, which stays at its current time. Nothing else — a new exception needs a written ask to the team lead, and gets added to this list or refused.

Friday. No cross-region meetings at all. The overlap hour is not used.

Owner. . Review date: <date, one quarter out>.

The exception list is the part that keeps it alive. An exception written down before launch is a rule; the same exception granted verbally in week three to someone with a genuinely urgent problem is a precedent, and precedents compound. The exception list for a protected day is built the same way and for the same reason.

Daylight saving will break it twice a year

Europe and North America do not change clocks on the same day, and the gap is not a rounding error.

The EU shifts on the last Sunday in March and the last Sunday in October. The United States shifts on the second Sunday in March and the first Sunday in November. So there is a week each spring and a week each autumn when one side has moved and the other has not, and every cross-Atlantic meeting silently slides by an hour relative to someone’s day.

In 2026 that autumn gap runs from 25 October to 1 November. A window defined as “16:00 Berlin” moves relative to New York for that week; the same window defined as “15:00 UTC” holds, and appears an hour earlier in Berlin instead.

Define the window in UTC, state which local times it maps to, and say what happens in the transition weeks — either the UTC time holds and locals shift, or the locals hold and you re-cut the UTC time twice a year. Both are defensible. Not deciding means two weeks a year where the policy is whatever each person’s calendar app guessed.

When the overlap is too small for core hours

If the arithmetic gives you an hour or less, core hours are the wrong instrument. You do not have a scheduling problem; you have a team whose working days barely touch, and the fix is structural rather than a calendar rule.

What to write instead:

• A single weekly synchronous slot, in the one hour that exists, with a standing agenda. One meeting, protected, never moved. Everything else is written.
• A written default. Decisions are made in a document with a named deadline, not in a call. This is where the policy actually lives, and if the writing goes unread the policy fails for reasons that have nothing to do with time zones.
• Handoff windows rather than overlap. Each region’s last hour is for writing what the next region needs. This is slower and it works at any spread, including zero overlap.
• No recurring meeting that requires more than two zones. Right-size the attendance instead of the clock.

Teams resist this because a weekly synchronous hour feels thin. It is thin. It is also what the arithmetic permits, and a policy that demands more than the arithmetic permits is the one that dies in month three.

What breaks first

In rough order of how early you will see it.

1. The person at the edge stops attending. Whoever carries the hour starts missing it, with reasons, and the reasons are good. This is the policy failing, not the person.
2. Someone books over it. A single meeting outside the window, by someone senior, in week two. The downgrade reply is the move here, and it works better than a flat refusal.
3. The hour fills up. If every cross-region meeting must sit in the one overlapping hour, you have created a daily meeting. The window is where meetings may go, not where they all go.
4. Nobody owns it. A policy with no named owner and no review date is a channel message. The three properties a policy needs to still be working in month three apply here unchanged.

Run the arithmetic again every time somebody joins, leaves or moves. It is ten minutes, and the overlap changes more often than anyone expects.

If you cannot set the policy

You probably cannot — most people reading this report to someone who would have to agree. Two things work from below.

Set your own window and publish it. Put a recurring busy block outside your genuine working hours, so a booking tool cannot offer the time. Then say it once, in writing, to the people who book you: “I’m online 10:00 to 18:00 Berlin time. Anything outside that I’ll need a heads-up for.” That binds nobody, but it moves the default.

Then do the arithmetic anyway and send it to whoever could set the policy. A table showing the team has zero overlap on a nine-to-five is not an opinion, which is why it travels further than any argument about load. The cost calculation persuades nobody on its own; the overlap table tends to land, because it ends an argument rather than starting one.