Scheduling Across Time Zones Without the Mental Math
Every remote team, every international friend group, and every freelancer with clients overseas has the same weekly ritual: trying to figure out what time "3pm my time" actually is for the other person. It sounds simple and it is — until daylight saving time changes on different dates in different countries, and the whole thing slips by an hour. This guide breaks the problem down so it stops costing you energy.
Why timezone math feels hard
The difficulty is not the arithmetic; it is that offsets are not fixed. Most of the world uses daylight saving time, but countries switch on different dates, some regions within a country do not switch at all, and a handful of places use half-hour or quarter-hour offsets. So "New York is UTC-5" is true for part of the year and wrong for the rest.
The result is that memorized offsets silently go stale. A meeting you scheduled correctly in summer is an hour off in winter, and you do not notice until someone sits in an empty call.
Rule one: compare against UTC, not against each other
The reliable mental model is to convert everything to UTC (Coordinated Universal Time), which never changes for daylight saving. If you know a time in UTC, any city's local time is just an offset away, and the offset is always applied relative to UTC.
So instead of trying to compute "Singapore to London", you convert both to UTC and compare. This single habit removes most of the error, because you are no longer doing a chain of offset subtractions in your head.
Rule two: name the time zone, not the city, in writing
Most miscommunication happens when people say "let's meet at 3" without anchoring it to a zone. The fix is to always write the zone or the offset explicitly: "15:00 UTC+8" is unambiguous, while "3pm" is not.
Even better, when you send an invite, use a tool that shows both sides' local times simultaneously. When both people see "your 9am / their 5pm" side by side, the ambiguity disappears before it becomes an argument.
Daylight saving: the one thing to double-check
Because the US and Europe change their clocks on different dates (and some countries never change at all), there is a window twice a year where a naive conversion is wrong. The practical rule: if your meeting is within a week of a daylight-saving transition, verify with a converter rather than trusting a remembered offset.
For most people this is the entire trick. Know that offsets drift, anchor to UTC, write the zone explicitly, and double-check near the transition dates. The rest is just looking up the current offset, which a converter does instantly.
A workflow that ends the confusion
When you need to schedule across zones:
- Open a timezone converter and pick the two cities.
- Drag your proposed time and read off both local times at once.
- Write the result as "our 09:00 / their 17:00" in the invite so everyone sees their own time.
This takes ten seconds and eliminates the class of scheduling errors that wastes the most real-world time. The tool does the offset lookup and the daylight-saving handling for you, so the only thing left for you to do is read two numbers off a screen.