How to schedule meetings across time zones without the mental maths
I missed a call with someone in London by an hour, and the reason was not carelessness. I had done the maths, twice, and got the same wrong answer both times, because I was subtracting from the wrong end and had forgotten that the UK had just come off daylight saving. That was the point where I stopped trusting my head with this. If you want to schedule meetings across time zones and stop losing calls, the fix is mostly about removing the arithmetic rather than getting better at it.
I have been working remotely from Korea, Taiwan, Japan, Thailand and Indonesia while most of the people I deal with sit in Australia, and a few in Europe. So this is not theory, it is a problem I have made every version of.
The four things that actually cause missed meetings
Almost every scheduling failure I have had traces back to one of these, and none of them are the obvious one of not knowing the offset.
Daylight saving does not move everywhere at once
Europe shifts on the last Sunday of March and October. The United States shifts on the second Sunday of March and the first Sunday of November. That leaves a few weeks each year where London and New York are four hours apart instead of the five everyone has memorised. A recurring meeting booked before the change quietly lands in the wrong hour, and nobody notices until someone joins an empty room.
Australia makes it worse, because our daylight saving runs the opposite way to the northern hemisphere. The gap between Sydney and London swings between nine and eleven hours across a year. Any offset you learned in July is wrong by January.
Not every offset is a whole hour
India is five and a half hours from UTC. Nepal is five and three quarters. Adelaide is nine and a half, and Darwin is nine and a half without ever changing for daylight saving whilst Adelaide does. If you round any of these to the nearest hour in your head, you will book something thirty minutes off, which is exactly the sort of near-miss that makes everyone late rather than absent.
The date moves, not just the clock
This one caught me properly. From Asia, a 9am Monday call in California is Tuesday morning for me. Agreeing to "Monday at 9" over a chat message with no date attached is how two people end up perfectly certain and a day apart. The clock gets all the attention and the calendar quietly does the damage.
Your phone knows where you are, which is not always helpful
Land in a new country and everything shifts to local time, including alarms you set to catch a call back home. I have woken up at what my phone thought was 7am and what my actual working day thought was the middle of the afternoon. The device is being helpful in a way that is precisely wrong for remote work.
The clock gets all the attention and the calendar quietly does the damage.
Pick one anchor zone and write everything in it
The single habit that fixed most of this for me was choosing one canonical zone for the working relationship and never writing a time in any other. For client work that is wherever the client sits, usually Sydney or Melbourne. For anything spread across three or more countries, UTC, because it never changes for daylight saving and nobody gets to feel like the default.
Then write the time properly. Not "Tuesday 3pm" but "Tuesday 5 August, 3pm Sydney time". The date kills the day-boundary problem and naming the city kills the offset problem, because your reader converts from a fact rather than from an assumption about where you are. It reads as slightly over-specified in a message. It is worth it.
Let the calendar do the conversion
Google Calendar and Outlook both store events with a time zone attached and re-render them wherever you open them. That machinery is reliable. The trouble is that people bypass it, agreeing a time in a chat thread and then creating the event from memory, which reintroduces the arithmetic at the exact moment it matters most.
A few things that help in practice:
- Turn on the secondary time zone in your calendar settings so two columns of hours run down the side. You stop converting because you can see both.
- Send availability rather than a single time. Three windows in your anchor zone, and let the other person pick. It also removes the polite back-and-forth where nobody wants to say the time is bad for them.
- For anything recurring, check it again after each daylight saving change rather than assuming the calendar handled it. Usually it did. Occasionally an invite was created with a fixed offset instead of a zone and it did not.
- Put the city name in the event title for cross-border meetings. It costs nothing and it is the thing people read on a phone lock screen at speed.
The alarm is the part that keeps failing
Getting the calendar right still leaves a gap. If you travel, your alarms are anchored to wherever your phone thinks it is, and the whole point of an early call with head office is that it is early. I have set an alarm the night before a Sydney call, flown, and had the alarm politely follow me to the new local time.
This is why I ended up building Meridian Clock. You anchor an alarm to a city, and it stays on that city's time when you cross a border, so a 6am Sydney call stays a 6am Sydney call no matter where you woke up. The alarm screen shows the city, the weather there and what the alarm is for, and the alarms are exact and survive a restart, which sounds like a small thing until an update reboots your phone overnight. That is the specific hole in my own workflow it was built to close.
The short version
Pick an anchor zone. Always write the date and the city with the time. Create the event in a calendar and let it convert rather than converting yourself. Check recurring meetings after each daylight saving shift. Anchor the alarm to the meeting's city instead of to where your body happens to be.
None of that is clever. It is mostly about accepting that mental time zone maths has maybe a ninety percent hit rate, and the ten percent is always the meeting that mattered. I still glance at a world clock most mornings out of habit, and I have not missed a call since I stopped doing the sums.
If you only change one thing, put the date and the city next to every time you send. It has saved me more meetings than any app has.
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.
More from the devlog.
Digital journal vs paper: which one you'll actually keep
I kept four paper notebooks badly and a digital journal for three years. The digital journal vs paper question is not really about depth or handwriting. It is about how much sits between you and the first sentence.
Readwise for physical books: what exists and what doesn't
Kindle highlights sync themselves. Paper highlights sit in the book forever. Here is what a Readwise for physical books setup actually looks like, where the tooling gives up and what I do instead.