The Problem With "Just Add 5 Hours"
Every distributed team eventually learns this the hard way: someone does mental timezone math, gets it wrong by an hour, and a meeting either starts with half the room missing or ends with someone dialing in at 11pm by mistake. The usual culprit isn't carelessness — it's that manual timezone math relies on a fixed offset ("New York is UTC-5") that is only true for part of the year.
Why Fixed Offsets Are Dangerous
Most of the world's major timezones observe Daylight Saving Time, but not on the same calendar dates. The United States shifts on one weekend in March and November; the European Union shifts on different dates entirely. For a few weeks each spring and fall, the gap between two timezones is not what it was the rest of the year. A spreadsheet formula with a hardcoded offset has no idea this happened — it just keeps producing a wrong answer, confidently, until someone notices a meeting landed an hour off.
What Actually Works: Timezone-Database-Aware Conversion
The fix isn't to memorize DST transition dates — it's to let software that already knows the full IANA timezone database (the same database your phone and laptop use) do the conversion for the specific date you're scheduling for, not a generic "always true" offset. That's the difference between a tool that quietly breaks twice a year and one that doesn't.
A Faster Way To Find The Window
Instead of converting one person's time at a time, it's far faster to see everyone's working hours laid out on a single 24-hour grid. Add each teammate with their timezone and their typical working hours, and let the grid highlight where the green (available) cells stack up across every row. The best meeting time is simply the column with the most overlap — no mental math, no spreadsheet, no DST surprise.
Tips For Distributed Teams
- Default to a rotating meeting time if your team spans more than 8 hours of difference — no single time is fair to everyone every week, so alternate who has to join early or late.
- Record working-hours windows honestly. If someone starts at 7am to catch an overlap, note that — don't assume a rigid 9-to-5 for a role that isn't.
- Re-check recurring meetings after DST changes. A meeting time that worked in July can land an hour off in December if it wasn't computed with real timezone-database logic.
- Use full IANA zone names like
America/New_YorkorAsia/Jakartainstead of abbreviations like "EST" or "WIB" — abbreviations are ambiguous and don't encode DST rules at all.
Bottom Line
Timezone scheduling mistakes are almost never about the people — they're about the math. Once the conversion itself is trustworthy, picking a fair, workable meeting time becomes a five-second glance at a grid instead of a support thread in Slack.
Frequently Asked Questions
Yes — it uses the browser's built-in Intl timezone engine (the same IANA timezone database your operating system uses) to compute each person's local time for today's actual date, rather than a fixed UTC offset. That means it stays accurate through every DST transition automatically.
There's no fixed limit — add as many teammates as you need, each with their own timezone and working-hours window. The overlap grid and best-window ranking recalculate instantly as you add or remove people.
Yes — Timezone Meeting Scheduler Finder does exactly that. Add everyone's timezone and working hours and it ranks the UTC hours with the most overlap. It's a one-time $5.99 purchase — no subscription, no account required.
Yes — every person you add has their own editable working-hours start and end time, so you can reflect early starts, late finishes, or non-standard schedules accurately.
No — once the page is loaded, everything runs locally in your browser using built-in timezone data. Nothing you enter is sent to a server.