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.

Meeting score = minimum(participant scores)

Per-participant scoring

1.0 — fully inside core hours (9 AM – 5 PM local).
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.

Meeting Time Zone Optimizer

Scoring Guide

Top Candidate Times (UTC reference)