Daylight saving time across time zones: why your meetings keep shifting

A weekly call I had held for months was suddenly sitting in my calendar at the wrong hour. Same invite, same people, same "10am" it had always said. I nearly dialled in an hour late, worked out why, and realised it was going to keep happening twice a year for as long as I kept working across time zones.

The culprit was daylight saving time across time zones. Everyone knows about the one-hour clock change. What catches you out is how it behaves between two countries that flip their clocks on different weekends, or where one side does not flip at all. If you schedule anything recurring, it is worth understanding once rather than being surprised by it every spring and autumn.

I spend a lot of the year based in Asia and I am Australian, so I am usually juggling at least three places at once: wherever I am sitting, home in Australia, and whoever I am actually talking to. That is where this first bit me, and it is a big part of why I ended up building a clock app around it. More on that later.

Why daylight saving time breaks meetings across time zones

The part that is not obvious is this: the offset you have memorised between two cities is only true for part of the year.

Say you have settled into "Sydney is three hours ahead of Singapore." For months that is correct, so you stop checking. Then Australia puts its clocks forward in October and Singapore does not, because most of Asia does not observe daylight saving at all. Now Sydney is four hours ahead, and every recurring call you anchored to that old three-hour gap is an hour out.

Nothing in your calendar looks wrong. The number just quietly stopped being true.

It gets messier when both ends change, but on different dates. The US moves on the second Sunday of March and the first Sunday of November. Europe moves on the last Sunday of March and the last Sunday of October. Australia goes the other way, forward in October and back in April, because it is in the southern hemisphere. So for a week or two around each changeover, two places sit on an offset that matches neither the summer gap nor the winter one.

The gap weeks nobody warns you about

Those in-between stretches are where I have made actual mistakes. Europe falls back on the last Sunday of October, the US a week later in early November. For that week in between, London and New York are five hours apart instead of the usual four. If you have a standing call pinned to "my 4pm," one side is now turning up at what feels like the wrong time, and nobody set out to move it.

The honest problem is that there is no alert for this. Your phone changes its own clock fine. What it cannot do is tell you that the mental shortcut you have been using for a call with someone in another country just expired for a fortnight. You find out when someone is sitting in an empty meeting.

Why "just use UTC" does not really fix it

The usual advice is to store everything in UTC and be done with it. It is tidier in theory, but it moves the problem rather than removing it.

Pin a recurring meeting to a UTC time and it stops drifting, but then it drifts for the humans instead. A 9am slot works for someone in California because it is tied to their local morning. Hold it steady in UTC and, when California changes its clocks, that same meeting lands at 8am or 10am for them. You have kept the number stable and made the actual experience worse. For a one-off timestamp in a database, UTC is the right answer. For a meeting two people have to physically show up to, what you want is to anchor it to a city and a date, and let that city's real local time carry the daylight saving change for you.

What actually works

After getting this wrong enough times, here is the short list I stick to now.

• Anchor meetings to a city, not an offset. "10am in Sydney" survives daylight saving. "UTC+10" does not, because the +10 itself changes.
• Put the city in the invite. Not "EST" or "AEST," the actual place. Abbreviations go stale the moment the clocks move, and half of us cannot tell the summer one from the winter one anyway.
• Check whether the other place even does daylight saving. Most of Asia does not. If you are calling Singapore, Tokyo or most of China, only your end is moving, which is somehow easier to forget than when both ends move.
• Re-check the recurring calls in the changeover weeks. Late October through mid-November, then again in March and April, give the standing ones a quick look before you trust them.

How I stopped doing the mental maths

The fix I actually wanted was a clock that just knew. Not a converter I had to open and feed two cities into every single time, but something always on that showed me the places I care about at their real local time, daylight saving already handled.

That is most of why Meridian Clock exists. You anchor an alarm or a clock to a city, and it stays on that city's actual time as the clocks shift and as you travel. If I have a 7am call with someone in London, I set it against London, and it rings when it is genuinely 7am there, not when my phone's idea of the offset thinks it should. It does not make daylight saving go away. Nothing does. It just means I am not the one holding the offset in my head and getting it wrong twice a year.

I still name the city in the invite and still glance at the recurring calls in changeover season. Belt and braces. But the day-to-day "what time is it there, really" question stopped being something I had to think about, which is most of the win.

Daylight saving is one of those things that feels trivial until it costs you a meeting. If you work across time zones, the one habit worth keeping is simple: stop trusting a remembered offset, and start pinning things to a place. The clocks will keep moving, you just do not have to track them by hand.

Built for this

Meridian Clock

An alarm and world clock for living across timezones. Anchor an alarm to a city and it stays on that city's time when you travel, with the weather and your next meeting right there when it rings.

Benjamin

Founder & sole developer, Novaire Digital