03:00 in Sydney
2 of 3 inside working hours. Fairness pressure 6.
Sydney 03:00, New York 12:00, London 16:00
Time Zone Meeting Planner
Remote work time
Formula, working and page tools
Build a meeting with real city time zones, see every participant's local clock on one UTC axis, and find the least-painful window before you send the invite.
Inputs
Build the meeting
09:00 in Sydney on is Tue, 24 Mar, 09:00 in Sydney and Mon, 23 Mar, 18:00 in New York and Mon, 23 Mar, 22:00 in London (outside working hours for 2 of 3 people).
Answer
2 outside working hours
09:00 in Sydney on is Tue, 24 Mar, 09:00 in Sydney and Mon, 23 Mar, 18:00 in New York and Mon, 23 Mar, 22:00 in London (outside working hours for 2 of 3 people).
Fairness pressure: 6 hour-equivalents. Lower is kinder.
Participants
| Place | Zone | Working hours | Meeting local time | Offset | |
|---|---|---|---|---|---|
| inside working hours | 09:00 to 17:00 | Tue, 24 Mar, 09:00 to 10:00 | UTC+11:00 | ||
| outside working hours | 09:00 to 17:00 | Mon, 23 Mar, 18:00 to 19:00 | UTC-04:00 | ||
| outside working hours | 09:00 to 17:00 | Mon, 23 Mar, 22:00 to 23:00 | UTC+00:00 (changes this week) |
Shared UTC timeline
Skipped local times resolve forward and repeated local times resolve to the first occurrence. If a row says the offset changes this week, check the invite text carefully before sending.
Best window finder
Top 3 alternatives on this date
02:45 in Sydney
2 of 3 inside working hours. Fairness pressure 6.25.
Sydney 02:45, New York 11:45, London 15:45
02:30 in Sydney
2 of 3 inside working hours. Fairness pressure 6.5.
Sydney 02:30, New York 11:30, London 15:30
Use it in code
meeting = {
"base_city": "Sydney",
"base_zone": "Australia/Sydney",
"date": "",
"time": "09:00",
"length_minutes": 60,
"first_local_result": "Sydney Tue, 24 Mar, 09:00"
}
print(f"{meeting['time']} in {meeting['base_city']} is {meeting['first_local_result']}")The snippets print the same first local conversion used by the planner.
Print Room
One-page meeting worksheet
CalculationTime meeting sheet
Sydney meeting
09:00
09:00 in Sydney on is Tue, 24 Mar, 09:00 in Sydney; Mon, 23 Mar, 18:00 in New York; Mon, 23 Mar, 22:00 in London. Meeting length: 60 minutes.
| Sydney | Tue, 24 Mar, 09:00 | 2026-03-24 | OK |
| New York | Mon, 23 Mar, 18:00 | 2026-03-23 | Outside hours |
| London | Mon, 23 Mar, 22:00 | 2026-03-23 | Outside hours |
Notes: ________________________________________________
Method
Time zones are offsets plus rules, not just arithmetic
UTC is the shared axis
Every row in the planner is drawn against the same UTC minutes. A 09:00 Sydney meeting in January 2026 is 22:00 UTC on the previous day because Sydney is on daylight time. In July it is 23:00 UTC because the offset is one hour smaller. Converting through UTC prevents the common mistake of comparing wall clocks directly. The timeline strip is just that rule made visible: the yellow meeting block is one instant, while each row labels it in a different civil clock.
Daylight saving changes the gap between cities
Sydney and London are not always the same distance apart. In January, Sydney daylight time is UTC+11 while London is UTC+0, so the gap is 11 hours. In July, Sydney is UTC+10 while London is UTC+1, so the gap is 9 hours. A "fixed" Monday standup can therefore shift by two hours for one side of the call. New York adds another trap in March, because the US and Europe change on different weekends, making a familiar tri-city meeting temporarily unfamiliar.
Half-hour and quarter-hour zones matter
India uses UTC+05:30 and Nepal uses UTC+05:45. A planner that only offers whole-hour offsets will quietly put these colleagues in the wrong slot. This page uses IANA zone names through Intl, so Kolkata and Kathmandu stay aligned even when the base city is on the other side of the date line. Lord Howe Island is another useful test case because its daylight saving shift is 30 minutes, not the more familiar full hour.
The date line is a calendar problem
A call can happen at the same instant while showing Tuesday for Auckland and Monday for Honolulu. The strip marks midnight and day changes because the calendar day is often the part people miss when they paste an invite into chat. The result sentence names the weekday for each row, not only the clock time. That is deliberately redundant: if someone only sees "09:00", the planner has not done its job; the calendar day is part of the answer.
"3 PM EST" is ambiguous
People often use EST to mean "Eastern time" all year, but EST is specifically standard time. In summer, New York normally observes EDT instead. The safer invite says the city or IANA zone, the date, and the local time for each person, then includes UTC as the neutral reference. The page avoids the CalculationTime API's older DST shortcut because a zone "uses DST" and a zone "is in DST at this instant" are not the same claim.
Fair scheduling rotates inconvenience
Remote teams can make one meeting work and still be unfair over time. A follow-the-sun rotation shares the early or late calls instead of making the same city absorb them. The fairness score here is deliberately transparent: inside working hours is best, near the edge is tolerable, and outside the window adds pressure. The top-three list is not meant to overrule people; it gives the organiser concrete alternatives to take back to the group.
Skipped and repeated times need to be named
On a spring daylight-saving change, a local time such as 02:30 may not exist; on the autumn change, a time such as 01:30 may happen twice. The supplied helper resolves skipped times forward and repeated times to the first occurrence, but the page still warns when offsets change nearby. Silent correction is dangerous in scheduling because the organiser may think everyone agreed to a normal wall time when the calendar is actually sitting on a transition edge. A visible warning is slower than a hidden guess, but it is far safer.
Questions people ask
Time Zone Meeting Planner: frequently asked questions
Why does the same meeting time move by one hour in March or October?
Different countries change daylight saving on different dates. A Sydney-New York-London call can have a different offset gap for a few weeks even if the wall-clock time looks familiar.
Does this use fixed UTC offsets?
No. The planner uses IANA time zones through Intl so city rules, daylight saving and half-hour offsets are calculated for the selected date.
What happens to skipped or repeated local times?
The supplied conversion helper resolves skipped times forward and repeated times to the first occurrence, then the page explains that the wall time is unusual rather than hiding it.
Can I invite someone in India or Nepal?
Yes. Kolkata uses UTC+05:30 and Kathmandu uses UTC+05:45, so the planner avoids whole-hour assumptions.
What is the fairness score?
It is a simple spread measure of inconvenience: a meeting inside working hours scores best, while very early, late or day-shifted rows add pressure to the score.
Can I share the meeting setup?
Yes. The state is saved in the URL hash, so a copied link can reopen the same places, date, time, duration and working-hour windows in the static export.
Certification notes
Source, method and limitation basis
The previous generic page only converted between two manually entered UTC offsets. This folder route upgrades the same slug into a city-zone planning tool. Reviewed 2026-09-23.
Model limits
This page is for meeting planning. Confirm legal deadlines, travel, broadcast releases and payroll cutoffs with the relevant official source.
Assumptions
- All conversions use Intl/IANA time zones through the supplied zoneTime helper.
- The CalculationTime API is not called at runtime.
- Skipped local times resolve forward and repeated local times resolve to the first occurrence, matching the supplied helper semantics.
- Working-hour fairness is a scheduling aid, not an HR policy.
Cite this page
Use the canonical URL, the page title “Time Zone Meeting Planner - CalculationTime”, and the review date 2026-09-23.