If you work with anyone across the Atlantic, chances are your calendar got a bit weird last week. Europe set its clocks back on 25 October; the US only did it on 1 November. For that one week, New York was 4 hours behind London instead of the usual 5, Chicago was 5 behind instead of 6, and every recurring meeting anchored on the “other” side of the pond quietly moved by an hour for half of its attendees.

Twice a year this happens, and twice a year someone joins a call an hour early (or an hour late) and the first 5 minutes of the meeting turn into a debate about whose clock is right. Having lived in London, then Silicon Valley, then Texas, I’ve had my fair share of these, and I’m still not immune to it 🙂

Now, people who don’t build software tend to see this as a people problem: “just check the time zone, mate”. Those of us who write calendar code know better. It’s a data problem, and it’s one that’s very easy to get wrong.

Store the Zone, Not the Offset

Here’s the classic mistake. You store a meeting as “09:00, UTC-05:00” because that’s what the offset was on the day the meeting was created. Nothing wrong with this, right? It’s a perfectly valid timestamp. Except an offset is a snapshot, not a location. New York is UTC-04:00 in summer and UTC-05:00 in winter, and the offset alone can’t tell you which one the organiser meant for next month’s occurrence. So the day the clocks change, your “9am meeting” turns into an 8am or 10am meeting, depending on which way you got it wrong.

The fix is boring and well known (which doesn’t stop people from getting it wrong): store the instant in UTC for a one-off event, and for anything a human thinks of as “9am my time”, store the zone itself, as an IANA zone id like America/New_York or Europe/London. Let the time zone database work out the offset for each date. It knows about every daylight saving rule, past and future, and you do NOT want to maintain that table yourself.

Zone ids are also what we went for in Calendrz. A Calendrz profile doesn’t have a time zone of its own: each connected account carries the zone id detected on its primary calendar, and a small helper works out which zone a user’s day starts in (the main account’s zone first, then the other accounts in a fixed order, so someone with calendars in two zones always gets the same answer). The agenda, the availability and the scheduler all go through that one helper, so they never disagree about when your Tuesday starts. It’s a tiny class, and it’s precisely the kind of code that saves you from a whole category of “why is my free slot an hour off?” bugs.

The Leadership Bit Nobody Talks About

The technical fix is the easy part. The harder part, if you lead a distributed team, is that every recurring meeting has a “home” time zone, whether you chose it or not, and the people outside that zone are the ones whose day shifts twice a year.

With the teams I’ve led and the companies I advise, I keep seeing the same pattern: the meetings that cause the most friction aren’t the ones at awkward hours (everyone knows about those and plans around them), they’re the ones that are fine for 50 weeks a year and terrible for 2. Somebody’s 8am stand-up becomes a 7am stand-up, they miss it a couple of times, and it gets read as a commitment problem when it’s really a calendar one. So decide explicitly which zone each recurring meeting lives in, write it in the invite, and rotate the inconvenience if you can. It’s a small thing, and it tells people you’ve noticed.

And Now the Agents Are Booking Meetings Too

Here’s what makes this more interesting nowadays: more and more of the scheduling isn’t done by people clicking around a calendar UI at all, it’s done by an AI assistant on their behalf. I’m a big believer that this is where things are heading (your agent does the clicking, filling in and navigating for you), but it raises the stakes on getting time zones right. A human who sees “4am” on a proposed meeting will spot the problem; an agent that assumes London is always 6 hours ahead of Chicago will happily send an invite that’s an hour out for half the people on it.

As such, if you’re building tools that agents call, return times with their zone ids, say in the tool’s description which zone a time is in, and never make the agent do offset arithmetic itself. (The Calendrz MCP tool that creates a meeting poll, for instance, asks the agent for an “IANA timezone, e.g. ‘Europe/London'” rather than an offset, and spells that out in the parameter’s description.) And if you’re the one asking the agent to book something across zones in the last week of October, check its homework 😉

Bottom line: the clocks will go back again next October, the US and Europe will disagree about it again, and somebody’s code will break again. Just make sure it’s not yours.