"Let's do 3pm." Whose 3pm? Yours, the colleague in San Francisco who is still asleep, or the client in Sydney for whom it is already tomorrow? A surprising share of the calendar invites that land an hour wrong start with exactly that sentence.
Coordinating a call across continents is a solved problem — you just need to see everyone's working hours at once instead of doing offset arithmetic in your head. If you'd rather skip the maths entirely, the Skojio timezone helper stacks every participant's zone on one 24-hour timeline, marks where the working days overlap, and hands you a link to share the exact slot.
- Most scheduling errors come from doing UTC-offset arithmetic by hand — and from forgetting that offsets change with daylight saving.
- The fastest way to pick a slot is visual: stack everyone's working hours on one timeline and look for the overlap.
- Communicate times in UTC, written as ISO 8601 with an offset, so there is never a "your time or mine?".
- Pin recurring meetings to a named zone like Europe/London, not a fixed UTC time, so they follow daylight-saving shifts.
- Time-zone drift breaks scheduled jobs the same way it breaks meetings.
Why scheduling across time zones goes wrong
The trap is assuming the gap between two cities is a fixed number. It is not. London and New York are five hours apart for most of the year — but for roughly two weeks each spring and autumn, when one region has changed its clocks and the other has not, the gap is four hours. Every "always five hours apart" rule of thumb is wrong twice a year.
Three things compound it:
- Bare local times. "3pm" carries no zone. The moment it leaves your calendar and lands in an email, half the recipients silently assume it means their 3pm.
- The date line. When it is 9am Monday in California, it is already 2am Tuesday in Sydney. Mental arithmetic that ignores the day rollover books people for the wrong date, not just the wrong hour.
- The wrong canonical reference. Teams store "the meeting time" as whatever the organiser's clock said, so when the organiser travels or their region shifts, the stored time moves with them.
Get those three straight and the rest is mechanical. Ignore them and you generate a steady trickle of missed calls that everyone blames on "time zones" rather than on arithmetic.
How to find a meeting time that works in every time zone
Stop converting in your head. The reliable method is visual: take each participant's working hours — say 09:00 to 17:00 local — translate them onto one shared axis, and look for the column where the bands overlap.
Worked example. A call between London, New York, and São Paulo:
- London (UTC+1 in summer): 09:00–17:00 local is 08:00–16:00 UTC.
- New York (UTC−4): 09:00–17:00 local is 13:00–21:00 UTC.
- São Paulo (UTC−3): 09:00–17:00 local is 12:00–20:00 UTC.
The only window all three share is 13:00–16:00 UTC — early afternoon in London, mid-morning in New York and São Paulo. Any slot in that band is inside everyone's working day.
src="/blog/figures/timezones-overlap.jpg"
alt="Three stacked 24-hour timelines for London, New York and São Paulo with each city's nine-to-five band shaded, and the 13:00 to 16:00 UTC overlap highlighted"
caption="Stack each city's working hours on one UTC axis and the shared window is obvious — here, 13:00–16:00 UTC."
/>
Rather than work that out by hand, drop each city onto the timeline and read the overlap straight off the grid. When the zones are far enough apart that no band overlaps — San Francisco and Sydney, classically — there is no good answer, only a least-bad one. Seeing that on screen is the point: it tells you to rotate the awkward slot between teams instead of always burdening the same people.
Anchor on whoever has the narrowest availability. If one person observes a school run or a hard 18:00 stop, their constraint defines the window — fit everyone else around it rather than finding a slot that suits the majority and quietly excludes them.
Store and share times in UTC and ISO 8601
Pick one canonical reference for every stored timestamp, and make it UTC. Convert to local only at the moment you display it. That single rule removes a whole category of bug, because the stored value never depends on where anyone happens to be sitting.
When you write a time down for a human, use ISO 8601 with an explicit offset: 2026-06-10T15:00:00+01:00. It is unambiguous, sorts correctly as text, and every calendar app parses it.
src="/blog/figures/timezones-date-terminal.jpg"
alt="A terminal rendering one UTC instant, 14:00 UTC, in London, New York and Sydney using the date command with the TZ variable, showing 15:00 BST, 10:00 EDT and midnight the next day in Sydney"
caption="One instant in UTC, rendered in three zones — note the DST-correct abbreviations and Sydney's date rollover."
/>
For sharing, the rule is the same: never write a bare "3pm" and hope. Send the ISO timestamp, or a link that renders the slot in each person's local zone so nobody has to count. The same drift that derails meetings also derails automation — a scheduled task set in the wrong zone fires at the wrong hour — which is exactly why the cron expression helper shows fire times in a zone you choose rather than guessing the server's.
Daylight saving: the shift that breaks recurring calls
Daylight saving is where "I'll just remember the offset" finally collapses. Regions switch on different weekends, the southern hemisphere runs opposite to the northern, and places like most of Arizona or the entire UTC-anchored server fleet never switch at all. The offset between any two of them is a moving target.
An offset is a fact about a moment, not a property of a city — and it changes twice a year.
The costliest version is the recurring meeting. Book a weekly call as a fixed UTC time and it will drift by an hour for half the attendees the next time a clock changes — they show up early or late for weeks until someone notices.
Pin recurring events to a named IANA zone (Europe/London, America/New_York), never to a fixed UTC offset. A calendar that knows the zone applies each daylight-saving transition automatically; one that only knows "+01:00" freezes that offset and silently shifts the call for everyone the moment the rules change.
Compare any time zones in one screen
When a call spans three or more zones, stop converting in your head and put them all on one timeline.
Skojio's timezone helper lays every zone on a single 24-hour grid, stays accurate through daylight saving by using live zone data, lets you drag the time to find a slot, and gives you a shareable link that opens in each colleague's own local time. It runs entirely in your browser — no account, no calendar permissions, nothing uploaded.
Recap
| Problem | Fix |
|---|---|
| Ambiguous "3pm" | Attach a zone, or send ISO 8601 with the offset |
| Offset arithmetic by hand | Stack zones on one timeline and read the overlap |
| Recurring call drifts at DST | Pin the event to a named zone, not a fixed UTC offset |
| No shared working hours | Rotate the awkward slot; share a link so no one miscounts |
Time zones are only hard when you do them in your head. Line the zones up on one screen, agree the slot in UTC, and share it as a link — the next "whose 3pm?" thread never gets started.
Top comments (0)