The week the clocks change: a checklist

The night the clocks change is a bad time to discover that the on-call handoff, the backup job, and the standing meeting were all described as “9:00 AM local” by three different people who did not mean the same instant.

This is a list for the person who owns the team calendar and the person who owns the jobs. It is not a full operations manual. If a step does not apply to you, skip it. The point is to look at the things that are defined in local time before the Sunday, not on the Sunday.

The Monday before

Send the new local times. Not “daylight saving this weekend.” For each recurring meeting that crosses a zone boundary, write both cities’ times for this week and both cities’ times for next week. Say which zone owns the event, because that is the hour that will not move. The invite ownership guide is how to choose that zone if you never did. The US and Europe gap weeks are the special case where the painful shift is often the second Sunday, weeks later, when the gap returns to normal. Do not only check the weekend the US changes. Check the weekend Europe changes too, and the weekend Australia changes, if those cities are on the calendar.

London and New York, Chicago and London, and the other transatlantic pages list the year’s stretches so you do not convert “last Sunday of October” by hand. Singapore and Sydney moves on Sydney’s dates, the first Sunday of April and the first Sunday of October, which are not the US dates and not the European ones. Cairo and London is worse: Cairo uses the last Friday of April and the last Friday of October, and the October order against London is not stable from year to year. Read that page’s schedule. Do not reuse a sentence from last October.

The hour that is missing, and the hour that happens twice

In the US, the spring change jumps from 2:00 AM to 3:00 AM local. The 2:30 AM hour does not occur. A job, a flight check-in, or an on-call alarm set for 2:30 AM local that night does not have a 2:30. In the autumn the 1:00 AM hour happens twice. A job that runs “every night at 1:30 AM local” can run twice, or the operator running it by hand can be unsure which 1:30 they are in.

Do not schedule a human handoff inside the lost or repeated hour. Move it to 4:00 AM or, better, to a time when people are awake. Airports and airlines have their own rules for the change night. If you are departing during it, read the ticket. Do not invent a conversion in the security line.

Jobs and SLAs

Anything stored as a local clock time needs a named zone next to it. “9:00 AM” in a runbook is incomplete. “9:00 AM America/New_York” is a fact. “9:00 AM Eastern” is almost a fact, and it is the phrase that gets copied onto a server whose zone database is a year out of date.

Cron that uses the machine’s local zone will follow that machine. Cron that uses UTC will not, which is what you want for a job that must not run twice. The argument for storing instants in UTC, and converting at the edges, is in why developers should store UTC. The checklist version is shorter: if the job’s purpose is “during the New York business day,” it needs a zone. If its purpose is “every six hours, forever,” it needs UTC.

An SLA written as “next business day” crosses this weekend badly. Define the business day in one city’s clock, and say what happens when that city is the one changing. A customer in London and an on-call rota in New York do not share a “next morning” on the change night.

On-call handoff is the human version of the same bug. If the handoff is “9:00 AM local” and the two people are in different zones, they were never handing off at the same instant. After one of them changes clocks, the gap between their 9:00 AMs has moved by an hour. Write the handoff as an absolute time for that week, in both zones, on the rota page. Then put it back to the usual rule the following week, on purpose.

What you can ignore

A meeting inside a single zone, with no guests elsewhere, moves with that zone and needs nothing from you except a reminder that the wall clock changed. A pair that does not observe daylight saving, such as Singapore with Tokyo, does not have a change week. Do not send those people a DST email. It trains them to ignore the next one, which might be about their public holiday instead.

The country rules, so you know which Sunday you are even in, are in daylight saving time rules by country. If a government changes a rule and your laptop has not picked up the new data, the laptop is wrong until it updates. This site reads the same data your browser has. Updating the browser is the fix, not a different article.