Add each participant and we'll rank candidate meeting times by how reasonable each hour is for everyone — not just the host.
minutes
to
Scoring Guide
Core hours
9 AM – 5 PM
Full score (1.0)
Edge hours
8 AM, 6 PM
Reduced score
Evenings
7–10 PM
Low score
Night/Early AM
10 PM – 7 AM
Avoid (0 score)
Top Candidate Times (UTC reference)
Ranked
Add this calculator to your website
How the score works
For each candidate UTC hour, the calculator converts to each participant's local time and assigns a fairness score from 0 to 1 based on how reasonable that hour is for them. We then take the minimum across participants — because a meeting that is great for four people but at 3 AM for the fifth is not a fair meeting.
0.7 — within acceptable hours but at the edge (your "8–18" window).
0.4 — evening (within 4 hours of acceptable window).
0.0 — middle of the night or very early morning.
Why minimum, not average?
Averaging hides asymmetric burden. A 10 PM meeting that scores 1.0 for three Asia-Pacific colleagues and 0.0 for one US colleague would average to 0.75 — looks fine, but it is still 10 PM for the lone American every single time. The minimum-score rule surfaces the person bearing the cost.
For recurring meetings
If a single fair time doesn't exist (the global span is too wide), rotate the cost: use the top pick this week, then the second pick next week. Each rotation should land the cost on a different participant.
Limits
Daylight saving rules vary; this calculator uses fixed UTC offsets you enter.
Day-of-week constraints (Friday afternoons, Monday mornings) are not modeled.
Cultural meal/prayer windows aren't factored — apply judgment on top of the score.
Frequently Asked Questions
What if no time scores "good" for everyone?
Then the global span is wider than the model can accommodate fairly. Options: (1) Split into two meetings with overlapping subgroups, (2) Rotate the meeting time — use the top pick this week, second pick next week, so the cost rotates across team members, or (3) Switch to async communication for that decision instead of forcing a synchronous call.
Why minimum score instead of average?
Average hides asymmetric burden. A 10 PM UTC meeting that scores 1.0 for three people in Singapore and 0.0 for one person in San Francisco averages to 0.75 — looks fine, but the SF person is up past midnight every single week. Minimum surfaces the worst-off participant, which is what fairness actually requires.
Why are the times shown in UTC?
UTC is the only zone that's the same for everyone. The candidate column shows UTC; each participant column converts to their local time. Using a single neutral reference avoids the "but who's hosting?" framing where the host's zone implicitly anchors the meeting.
How do I handle daylight saving time?
The calculator uses the fixed UTC offset you select. Most major DST regions switch in March and October/November, shifting by 1 hour. If you're scheduling for a date that crosses a DST boundary, pick the offset that will apply on the meeting date — not necessarily today's.
Should "edge" hours (8 AM, 6 PM) really score lower?
For most knowledge work, yes. People near the edge of their day have less buffer for meeting overruns, are more likely to be commuting or in transition, and feel scheduled meetings as friction. If your team explicitly likes early/late meetings, treat the calculator output as conservative.
Tactics for distributed teams
Rotate the cost: if no fair time exists, document a rotation schedule so everyone bears the awkward hour equally.
Default to async: most recurring meetings can be replaced with a written update + targeted Q&A.
Anchor the day: pick a small "overlap window" all participants commit to being available within. Schedule synchronous work only inside it.
Record everything: when fair times don't exist, recordings let anyone who skipped catch up async.
Practical Guide for Meeting Time Zone Optimizer - Find Fair Meeting Times Across Zones
Meeting Time Zone Optimizer - Find Fair Meeting Times Across Zones is most useful when the inputs reflect the situation you are actually planning around, not a best-case estimate. Treat the result as a decision aid: it gives you a structured way to compare assumptions, spot outliers, and decide what to verify next. For Everyday Life work, the most important review lens is real usage patterns, constraints, time cost, comfort margin, and the habit you can actually maintain.
Start with a baseline run using values you can defend. Then change one assumption at a time and watch which output moves the most. If one input dominates the result, spend your verification time there first. If several inputs have similar influence, use a conservative scenario and an optimistic scenario to create a practical range instead of relying on a single exact number.
Before acting on the result, compare the result with recent receipts, schedules, measurements, or device data before changing routines. This is especially important when the calculator supports a purchase, project plan, performance target, or operational decision. The calculator can make the math consistent, but the quality of the conclusion still depends on current data, clear units, and assumptions that match your real constraints.
Review Checklist
Confirm every input uses the unit and time period requested by the calculator.
Run a low, expected, and high scenario so the answer has a useful range.
Check whether rounding or a missing decimal place changes the decision.
Update the calculation whenever usage patterns, household size, equipment, or schedule constraints change.