A rota that covers the phone line is not a fact about your teams. It is a fact about your teams on a date. Governments move their clocks on different weekends and in opposite directions, so the distance between two of your offices is not a constant, and a handover that worked all winter can quietly stop working in the spring with nobody having touched it.
This page takes several teams, their named time zones and their recurring local hours, and works out what that actually produces over a range of dates: the hours of the day somebody is on the phone, the stretches when nobody is, the longest of those stretches, and how much overlap each handover really has.
Plan your own
Who is on the phone, and where
A named zone, such as America/Toronto. A fixed offset like UTC-5 is refused on purpose: it is a reading, not a rule, and it stops being true twice a year.
The period you are planning
Every result below is in this zone. Each team keeps its own.
Below this, a handover is flagged as thin. With none at all it is flagged as a dropped baton.
Your rota stays in your browser. Nothing is uploaded.
- : a date has to be written 2026-12-25.
- : a date has to be written 2026-12-25.
A rota that stops working in July
The schedule loaded above is the one this page starts with. Three teams, London, Toronto and Sydney, each working an eight and a half hour weekday shift on their own local clock: 06:00 in London, 09:00 in Toronto, 09:00 in Sydney. Nobody works a night. Between them they cover the whole weekday clock, with half an hour of overlap at each handover.
In July the same three shifts leave a 1 h 30 min hole every weeknight. Toronto moved forward an hour in March, Sydney moved back an hour in April, and the half hour those two shared became a gap. Nobody changed the rota. Nobody could have seen it in a spreadsheet of local start times.
| Period | Hours covered | Stretches with nobody there | Longest | Handovers with no overlap |
|---|---|---|---|---|
| A midweek in January 2026-01-13 to 2026-01-14 | 100% | 0 | None | 0 |
| A midweek in July 2026-07-14 to 2026-07-15 | 93% | 2 | 1 h 30 min | 2 |
Both rows are produced by running the planner on this page over the same three teams, and the same two results are assertions in npm run check:coverage. The January row asserting no gaps at all matters as much as the July row: a checker that only ever finds faults cannot tell a working detector from one that fires on everything.
A UTC offset is not a schedule
The most common way a coverage plan goes wrong is writing down an offset. Read Toronto today, see UTC-4, put it in the spreadsheet, and every date after the first Sunday in November is an hour out. Nothing errors. The spreadsheet still adds up. The person on call simply is not there when the plan says they are.
An offset is a reading taken at an instant. A zone is a rule. The rules live in the IANA time zone database, which every browser ships and updates, and they include which weekend each region moves on, in which direction and by how much. Not every change is an hour: Lord Howe Island moves thirty minutes. Not every zone is on the hour: India is thirty minutes past, Nepal and the Eucla goldfields are forty-five.
| Date | America/Toronto | Europe/London | Australia/Sydney | Toronto to London | Toronto to Sydney |
|---|---|---|---|---|---|
| 15 January | UTC-05:00 | UTC+00:00 | UTC+11:00 | 5 hours | 16 hours |
| 15 March | UTC-04:00 | UTC+00:00 | UTC+11:00 | 4 hours | 15 hours |
| 15 July | UTC-04:00 | UTC+01:00 | UTC+10:00 | 5 hours | 14 hours |
| 27 October | UTC-04:00 | UTC+00:00 | UTC+11:00 | 4 hours | 15 hours |
Read the last two columns rather than the first three. Toronto and London are five hours apart in January and in July, and four hours apart in the middle of March and the end of October, because for those few weeks one region has changed and the other has not. Toronto and Sydney are sixteen hours apart in January and fourteen in July, because the two hemispheres move in opposite directions and the gap swings by two hours a year.
This tool therefore refuses a fixed offset as an input. Typing UTC-5 into the zone field gets you a message rather than a plan, which is the honest answer: an offset cannot express a recurring rule, and a planner that accepted one would be producing confident, wrong schedules for part of every year.
What this answers, and what it does not
It answers one question: is anybody there to answer the phone, and if not, when. It is not a meeting planner. It is not looking for a convenient hour on one day for a group of people; it is checking a recurring rota against a range of dates and reporting the holes.
It is also not a rota. It will not tell you who works which shift, respect anybody’s contracted hours, place breaks, or notice that you have put the same person on two shifts at once. It takes the shifts you describe as given and tells you what they cover. Building the schedule is your job; checking it is this.
It knows no holidays. Closure dates are typed in per team, because worldwide holiday data is a licensing and subdivision problem that adds nothing here, and because your own closures are the ones that matter anyway. And it says nothing about how many people each shift needs. That is a different question with a different answer, and it is what the staffing calculator is for. This one answers when somebody is available; that one answers how many of them there have to be.
How it works underneath
Every shift boundary is resolved as a wall-clock reading on its own local date, by asking the browser what a named zone’s clock says at a candidate instant and correcting until the two agree. The end of a shift is resolved separately from its start rather than being the start plus a duration, which is why an overnight shift comes out seven hours long on the night the clocks go forward and nine on the night they go back. Adding a duration would report eight on both, and be wrong twice a year in opposite directions.
Two readings need a decision rather than a conversion. On the morning clocks go forward, an hour of local time never happens, so a shift boundary inside it is placed at the transition itself, found by bisecting rather than by assuming the step is an hour. On the morning they go back, an hour happens twice, and the rule here is that the schedule never claims coverage the clock did not show: the later reading is taken at the start of a shift and the earlier one at its end, so the shift shrinks rather than grows. Every shift touched by either case is listed under “what the clocks did”, because a gap that appears on one night of the year needs its reason attached.
From there it is interval arithmetic. Shifts are merged into the hours somebody is on the phone; the hours you promise are built the same way in the display zone; the gaps are what is left after subtracting one from the other. A handover is the moment a shift belonging to a different team takes over the furthest point coverage reaches, and its overlap is how long both teams were on at once. A negative overlap is a hole, and an overlap of exactly zero is treated as a dropped baton rather than as a tidy handover, because the last call of a shift can still be live when the person who took it has gone.
The hour strip is counted in real minutes rather than in slots. On the day the clocks go forward, one of its twenty-four hours is zero minutes long and the day totals twenty-three; on the day they go back, one lasts two hours and the day totals twenty-five. Both are asserted in the check script, because a planner that assumed twenty-four equal hours would be wrong on exactly the two days it exists to explain.
All of it runs in your browser, in Intl calls and a few array walks. There is no endpoint behind this page: a rota is a list of who works when and where they live, and that is none of ours. The time rules themselves come from the IANA database inside your browser and change when governments change them, so a browser that has not been updated in a while is answering from older rules.
Questions
How do I work out when nobody is answering the phone?
Write down every team that answers, the named time zone each one is in, and the local hours they work. Convert each shift to one shared clock, on each date separately, then look for the stretches nothing covers. Doing it by hand is possible for two teams and unreliable for three, because the conversion is not the same on every date of the year. The planner above does it for a whole date range and prints the stretches with nobody on the phone, longest first.
Why do coverage gaps appear when the clocks change?
Because regions do not change on the same weekend, and the southern hemisphere changes in the opposite direction. North America moves in March and November, Europe in late March and late October, Australia in October and April. So the distance between two teams is not a constant: Toronto and London are five hours apart most of the year and four for a few weeks in spring and autumn, and Toronto and Sydney move by two hours over the year. A handover that shared half an hour all winter can share nothing at all in July, and nobody edited the rota.
What is a follow the sun support rota?
Teams in different parts of the world covering one phone line in sequence, so that each is working its own normal daytime and the line is answered around the clock. It works when the handovers overlap: the team going off has time to say what is outstanding before the team coming on is alone with it. It stops working the moment a handover has no overlap left, and the usual reason for that is a clock change in one region and not the other.
How much overlap should a handover between two support teams have?
Enough to hand over what is outstanding, which for a phone line usually means fifteen to thirty minutes. The number matters less than whether it exists at all. A handover with no overlap means the last call of one shift can still be live when the only person who knows about it has gone home, and there is nobody to tell. The planner flags a handover with no overlap separately from one that is merely thinner than you asked for, because they are different problems.
Why does this refuse a fixed offset like UTC-5?
Because a fixed offset is a reading taken on one day, not a rule. Toronto is five hours behind UTC in January and four in July, so a schedule built on UTC-5 is an hour wrong for eight months of the year, and it is wrong quietly. Named zones such as America/Toronto carry the rules themselves, including which weekend the change lands on, so a conversion done at a specific date is right at that date. The tool asks for a named zone and refuses an offset for exactly that reason.
Does this know about public holidays?
No, and that is deliberate. Holiday data has to be right about subdivisions, observances, moved dates and the rules for a holiday falling at a weekend, and getting it wrong is worse than not having it. You type your closure dates in yourself, per team, and they go into the plan and into the export. Your own closures are also the ones that matter: a team that works through a national holiday and closes for a local one is normal, and no list knows that.
Once you know when nobody is there
A plan tells you where the holes are. Something still has to decide what a caller hears when they ring into one: your opening hours, your closure dates and one switch for the day something goes wrong. That decision happens before any phone rings, and it is the same decision whether the hole is a Sunday or ninety minutes on a Tuesday night in July.