Store every shift in UTC, show it to each person in their own local time, and build the week around the hours when two zones overlap. Then check the schedule again whenever a country changes its clocks, because the overlap moves even though nobody’s local hours did. This guide walks through a four-person team in London, Bengaluru, New York and Tokyo, with the UTC math written out.
What does a time zone schedule need to get right?
Three things. Each shift has one fixed meaning, each person sees it in their own time, and someone can tell where coverage ends.
The first is the hard part. “9 to 5” means nothing until you say where. A shift is a start and an end in a person’s own zone, and the zone’s rules decide what that is in UTC on any given day.
In Buffer’s State of Remote Work 2023 report, 62% of respondents said people on their immediate team are spread across multiple time zones, and 14% named working across time zones as their biggest struggle (Buffer, checked October 2026).
How do you find overlap hours and coverage gaps?
Convert every shift to UTC and put them on one line. Then read off two numbers: where two people are on at once (overlap), and where nobody is (gap).
The worked example assumes:
- The date is Tuesday, October 27, 2026.
- Europe changed its clocks on Sunday, October 25, so London is on GMT, which is UTC+0 (GOV.UK, checked October 2026).
- The US has not changed yet. Its clocks go back on Sunday, November 1, so New York is still on EDT, which is UTC-4 (Wikipedia, checked October 2026).
- Bengaluru is UTC+5:30 and Tokyo is UTC+9. Neither country uses daylight saving time (India, Japan, both checked October 2026).
| Person | City | Local shift | Offset on Oct 27 | UTC shift |
|---|---|---|---|---|
| Kenji | Tokyo | 07:00 to 15:00 | UTC+9 | 22:00 (Mon) to 06:00 |
| Arjun | Bengaluru | 09:30 to 17:30 | UTC+5:30 | 04:00 to 12:00 |
| Sofia | London | 09:00 to 17:00 | UTC+0 | 09:00 to 17:00 |
| Maya | New York | 09:00 to 17:00 | UTC-4 | 13:00 to 21:00 |
Kenji’s Tuesday morning shift starts on Monday evening in UTC, so keep a date next to every UTC time.
Now the same week as a coverage line:
| UTC hours | Who is on | People on at once |
|---|---|---|
| 22:00 to 04:00 | Kenji | 1 |
| 04:00 to 06:00 | Kenji, Arjun | 2 (overlap) |
| 06:00 to 09:00 | Arjun | 1 |
| 09:00 to 12:00 | Arjun, Sofia | 2 (overlap) |
| 12:00 to 13:00 | Sofia | 1 |
| 13:00 to 17:00 | Sofia, Maya | 2 (overlap) |
| 17:00 to 21:00 | Maya | 1 |
| 21:00 to 22:00 | Nobody | 0 (gap) |
Four people, each working an ordinary day, cover 23 of 24 hours. The three handoffs have 2, 3 and 4 hours of overlap. Arjun and Maya never overlap, and neither do Kenji and Sofia, so anything between those pairs has to pass through the person in the middle. The only gap is 21:00 to 22:00 UTC, which is 06:00 to 07:00 Wednesday morning in Tokyo and 17:00 to 18:00 in New York.
What happens when daylight saving time changes?
The overlap moves even though nobody’s local hours change, and most teams don’t notice until a meeting breaks.
Look at the weeks in the example. Europe moved on October 25. The US moves on November 1. For that one week, London and New York are four hours apart instead of five. In spring the gap is longer: the US moves on the second Sunday of March (March 14, 2027), while Europe moves on the last Sunday (March 28, 2027), so the two sit out of step for two weeks (Wikipedia, EU, checked October 2026).
The same team on Tuesday, November 3, after the US change: New York is on EST, UTC-5. Everyone else is unchanged.
| Person | Local shift | UTC shift on Nov 3 | Change from Oct 27 |
|---|---|---|---|
| Kenji | 07:00 to 15:00 | 22:00 (Mon) to 06:00 | None |
| Arjun | 09:30 to 17:30 | 04:00 to 12:00 | None |
| Sofia | 09:00 to 17:00 | 09:00 to 17:00 | None |
| Maya | 09:00 to 17:00 | 14:00 to 22:00 | One hour later |
Maya’s shift slides one hour later in UTC. The Sofia and Maya overlap shrinks from four hours (13:00 to 17:00) to three (14:00 to 17:00). The 21:00 to 22:00 gap closes, because Maya now works until 22:00 UTC, exactly when Kenji starts.
Overnight shifts have their own trap. A London shift of 22:00 to 06:00 is 8 hours on a normal night, 9 when the clocks go back and 7 when they go forward. Decide ahead whether you count clock hours or scheduled hours, and tell people.
How do you show shifts in each person’s local time?
Store the shift once, in a zone-aware form. Show it in the viewer’s zone. Do not copy it by hand into each person’s calendar.
- Store the start and end with the person’s zone name (for example, America/New_York), not a fixed offset like “UTC-4”. A zone name knows about daylight saving time. A fixed offset does not.
- Show each person their own hours first. Show a teammate’s hours in the viewer’s local time when they look at someone else.
- Label every time with its zone. “13:00” alone is a bug waiting for a Slack thread.
- Publish a calendar feed so the shift appears next to the rest of someone’s week. The feed does the conversion in the calendar, not in a person’s head.
How do you set it up, step by step?
- List the people and their home zones. Use city names, not abbreviations. “IST” means India, Ireland and Israel depending on who reads it.
- Set each person’s local hours. Keep them as a normal local day where you can. People sleep best on a regular local clock.
- Convert to UTC for one specific date and put the results on a single line, as in the table above. Mark overlaps and gaps.
- Decide what the overlaps are for. Handoffs, standup, review. Put the shared meetings inside the overlaps, not at the edges of someone’s shift.
- Close or accept each gap. Our example has one hour with nobody on. Either accept it, write down who is on call, or shift one person by an hour.
- Rotate the awkward hours. If someone must start early or finish late to cover a gap, take turns. Write the rotation down so it is fair and visible. Give notice well ahead, and pay for the extra time per local rules.
- Put the clock changes on the calendar. Add the next US and Europe change dates and check the overlap table the week before each one.
How do payroll and overtime work across zones?
Pay follows the rules of where each person works, not where the company is based. Overtime thresholds, rest periods and holiday calendars differ by country and sometimes by state. Check them for each location, or ask your payroll provider.
Two practical points help in any country. Count a shift that crosses midnight as one shift, in the worker’s own zone, so it does not split into two part days. And keep a plain record of hours worked per shift, so payroll starts from one number.
How can Ruam help?
Ruam is automatic time tracking for remote teams, with no screenshots and one flat price. Its shifts feature is built around the problems above.
- Each person’s shifts are set in their own time zone, overnight shifts included. An overnight shift counts as one shift.
- Shift templates cover fixed, varied or flexible hours. You can change a single day without changing the template.
- A change request goes to the approvals list, and the manager approves or declines it.
- Each person gets a personal calendar feed of their shifts.
- Ruam counts inside the shift, plus an overtime window you set from 0 to 60 minutes. Work outside that is not counted.
- Reports show attendance against the schedule: who worked their planned hours, who started late, who is off. Breaks are shown, never scored.
Shifts are on the Team plan, $99 a month for unlimited people, with 7 days free and no card. If you manage people in several zones, Ruam for managers shows how a week looks from the manager’s side.
What should you do next?
Open a spreadsheet and build the UTC table for your own team, using a specific date. Mark the overlaps and the gaps. Then look up the next clock change for every country you work in, and put the week before it on the calendar. Most of the problems in this guide show up in that table first.