Why clock changes leave holes in phone coverage

A rota that covers your phone line is not a fact about your teams. It is a fact about your teams on a date. Regions change their clocks on different weekends and in opposite directions, so a handover that shared half an hour all winter can share nothing at all in July.

Nobody edits a shift. The rota simply stops covering. Here is a schedule that does exactly that, and the three things to check so it does not happen to yours.

Three teams, one published number, nobody working a night shift:

On a Tuesday in January, converted to one shared clock, that comes out as:

Sydney 22:00 (Mon) -> 06:30 London 06:00 -> 14:30 Toronto 14:00 -> 22:30 Sydney 22:00 -> 06:30 (Wed)

Every weekday hour is covered, and each handover shares thirty minutes: long enough for the team going off to say what is still open before the team coming on is alone with it. This is the schedule a planning meeting approves, and it is genuinely correct in January.

Nobody touched it. Toronto went forward an hour on the second Sunday in March. Sydney went back an hour on the first Sunday in April. London went forward on the last Sunday in March, which mostly cancels out against Toronto and is why the London handovers survived.

The same Tuesday in July:

Sydney 23:00 (Mon) -> 07:30 London 05:00 -> 13:30 Toronto 13:00 -> 21:30 ...nobody, 21:30 -> 23:00 Sydney 23:00 -> 07:30 (Wed)

An hour and a half every weeknight with nobody on the phone. The half hour Toronto and Sydney used to share went to zero and then past it, because one of them moved towards UTC and the other moved away from it at the same time of year.

That is the failure worth internalising: the two teams that lose a handover are the ones in opposite hemispheres, and the change happens in April, five weeks after everybody had stopped thinking about the March one.

There is no world daylight-saving date, and there is no reason there would be.

• North America moves on the second Sunday in March and the first Sunday in November.
• Europe moves on the last Sunday in March and the last Sunday in October.
• Australia and New Zealand move in October and April, in the opposite direction, because their summer is the other half of the year.
• Much of the world, including India, most of Africa and most of Asia, does not move at all.

So there are two windows every year, several weeks long, when North America and Europe are an hour closer together than usual. In 2026 those windows are 8 March to 29 March, and 25 October to 1 November. Anything scheduled by a difference rather than by a pair of local clocks is wrong for both of them.

Not every change is an hour, either. Lord Howe Island moves thirty minutes. And not every zone sits on the hour: India is thirty minutes past, Nepal and the Eucla goldfields are forty-five. A rota built out of whole-hour arithmetic has already lost.

These rules live in the IANA time zone database, which ships inside every browser and operating system and is updated whenever a government changes its mind. That last part is the reason a rota needs re-checking rather than approving once: countries have abolished daylight saving, adopted it, moved their standard offset, and in one case changed the rule with a few weeks' notice.

It writes down an offset. Somebody reads Toronto today, sees UTC-4, and puts it in a column. Every date after the first Sunday in November is then an hour out. Nothing errors, the sheet still adds up, and the person on call simply is not there when the plan says they are. The fix is to store the zone name and convert at each date, never to store the difference.

It adds a duration to a start time. A shift written as 22:00 to 06:00 is eight hours on an ordinary night, seven on the night the clocks go forward and nine on the night they go back, because both ends are clock readings and the clock moved between them. Adding eight hours to the start gets both of those nights wrong, in opposite directions.

It assumes every local time exists exactly once. On the morning clocks go forward, an hour of local time never happens: a shift starting at 02:30 that day starts at no real moment at all. On the morning they go back, an hour happens twice, so 01:30 is two different instants an hour apart. Both need a decision, and the safe one for coverage is to never claim an hour the clock did not show.

Three checks catch nearly all of it.

1. Check the shoulder weeks, not the solstices. The dangerous dates are mid-March, late October and early April, when one region has changed and another has not. A rota that works in January and July can still be broken for five weeks in between.
2. Check the handover, not the total. Coverage of ninety-five percent sounds fine and can mean a ninety-minute hole every night in the same place. The number that matters is the overlap at each handover, and whether it exists at all.
3. Check the teams furthest apart in latitude, not longitude. Two northern teams drift by an hour for a few weeks. A northern team and a southern one drift by two hours, twice, and in opposite directions.

If the answer is that there are hours with nobody there, that is not automatically a staffing problem. Sometimes it is, and then the question becomes how many people have to be free during the hours you do cover. More often the right answer is to decide deliberately what a caller hears in the hole, which is the same decision as any other after-hours choice: your opening hours and your closure dates decide it before any phone rings.

The support coverage planner takes your teams, their named zones and their local hours, and runs the arithmetic above over a range of dates. It gives you the hours of the day somebody is on the phone, the stretches when nobody is, the longest of those stretches, and the overlap at each handover, with a handover of zero overlap flagged separately from one that is merely thin.

It runs in your browser, nothing is uploaded, and the schedule it exports carries its assumptions in the same file: the zones, the dates, the closure dates you typed, and the fact that every conversion was done at the date it applies to. Closure dates are typed in by hand on purpose, because worldwide holiday data is a licensing and subdivision problem, and because your own closures are the ones that matter anyway.

Knowing where the holes are is the first half. What a caller meets when they ring into one is your hours, your closures and one switch for the day something goes wrong, and if the answer turns out to be another person on the phones, what a seat costs is the other half of that decision.