Cross-timezone scheduling

You find the time that works best for the people who matter most, without anyone guessing what time it is somewhere else. Every proposed time is computed with real time-zone rules (never mental arithmetic), checked against calendars, working hours and public holidays, and shown in each attendee's own local time with the day of the week. When no time is good for everyone, you say so and propose the fairest compromise.

When to use

• "Find a time for me, Priya in Bangalore and Sam in New York next week."
• "Set up a weekly team call that's fair to everyone."
• "When's a good time to call the Sydney supplier?"
• "Move Thursday's meeting; Sam can't make it."
• Anything involving dates near a daylight-saving change.

What you need

• Attendees, which of them are required and which optional, the meeting length, the window (dates), and any constraints (not Fridays, before a deadline).
• Each person's IANA time zone (for example Europe/London, Asia/Kolkata, America/New_York), working hours, and country and region for public holidays. Save these in memory once known.
• Free and busy time: calendars connected on the Connections page (Google Calendar, Outlook), your own browser signed in by the owner, or teammates' availability via ask_teammate. External people: ask them for windows, or propose options.
• The owner's rules: is booking on their behalf allowed, and for whom? Save in memory.

Method

1. Normalise everyone to IANA time zones. Never use abbreviations like EST or IST as inputs: they are ambiguous and ignore daylight saving. Use Python's zoneinfo, which knows each zone's rules.
2. Check for daylight-saving changes in the window. Different countries change clocks on different dates (for example the US and Europe change on different weekends in spring and autumn), so the gap between two cities can move by an hour for a week or more. Recurring meetings that cross a change need checking on both sides of it. zoneinfo handles this if you compute each occurrence separately.
3. Public holidays for each person's country and region: the holidays Python package (free, MIT licence), or web_search for the official list. Remove holidays and weekends (and local weekend days where they differ).
4. Pull busy time from connected calendars for the window (free and busy only; do not read meeting contents you do not need).
5. Score every candidate slot (15-minute steps) with execute_code (code in references/timezone-code.md): for each person, minutes outside their working hours; required people outside hours by more than an agreed limit (for example 60 minutes) or busy make the slot invalid; optional people count for less. Lower total is better. Prefer avoiding lunch hours and the very end of anyone's Friday.
6. Pick three options, spread across different days or times so people have a real choice, and present each in every attendee's local time with weekday and date, plus UTC. Flag anyone pushed outside their hours, by how much, and anyone for whom it falls on a different date.
7. If no slot works for all required people, say so plainly and offer: split into two sessions, a rotating time, an asynchronous update for the least-overlapping person, or the owner choosing whose evening it is.
8. Recurring meetings: rotate the pain. If the best fixed slot always hits the same person's evening, propose alternating between two slots (week A, week B) so the inconvenience is shared, and show the yearly total of out-of-hours minutes per person for each option.
9. Book or propose. Internal attendees: create the invite only if the owner asked you to book. External attendees: send options for them to choose, or book only with the owner's go-ahead. Invites state the time zone explicitly and include joining details. Calendar invites carry the time zone, so check the invite shows the right local time for each person.
10. Confirm. After booking, read back the event from the calendar and check each attendee's local time once more.

Worked example: London, Bengaluru and New York, 45 minutes

Required:

• Alex, Europe/London, 09:00 to 17:30.
• Priya, Asia/Kolkata, 10:00 to 18:30.
• Sam, America/New_York, 08:30 to 17:00. Optional: Mia, Australia/Sydney. In October the three required working days overlap only from 13:00 to 13:30 London (17:30 to 18:00 Bengaluru, 08:00 to 08:30 New York), so every 45-minute slot pushes someone a little. The scorer in references/timezone-code.md ranks 13:15 London best: Priya finishes at 18:30 exactly and Sam starts 15 minutes early.

  Option	Alex (London)	Priya (Bengaluru)	Sam (New York)	UTC	Outside hours
  1	Tue 13 Oct 13:15	Tue 13 Oct 17:45	Tue 13 Oct 08:15	12:15	Sam 15 min early
  2	Wed 14 Oct 13:15	Wed 14 Oct 17:45	Wed 14 Oct 08:15	12:15	Sam 15 min early
  3	Thu 15 Oct 13:15	Thu 15 Oct 17:45	Thu 15 Oct 08:15	12:15	Sam 15 min early
  Monday 12 Oct is excluded: a public holiday in New York. Mia would be at 23:15 on every option, so she gets the notes and a recording rather than an invite.

The clock-change trap

• Europe moves its clocks on the last Sunday of October; the United States on the first Sunday of November. For that one week the London-to-New York gap is 4 hours, not 5.
• A weekly 13:15 London call that is 08:15 for Sam becomes 09:15 that week, then 08:15 again.
• India and most of Asia do not change clocks at all, so their gap to Europe moves twice a year.
• Compute each occurrence separately with zoneinfo (the loop in the reference does this), and warn the people whose local time moves, in the invite and in a reminder the week before.

Invite text

Title: Q4 planning (45 min)
When: Tue 13 Oct 2026, 13:15 to 14:00 London (BST) / 17:45 Bengaluru / 08:15 New York
Agenda: 1. Q3 numbers  2. Q4 priorities  3. Hiring
Join: <link>
If this time does not work, reply with two windows that do and I will rearrange.

Always state the organiser's zone and each attendee's local time. "13:15 BST" alone makes Sam do the arithmetic you were hired to do.

Output

• Three options as a table: option, date and time in each attendee's local time (weekday included), UTC, who is outside hours and by how much.
• A recommendation with one line of reasoning.
• For recurring meetings: the rotation plan and each person's yearly out-of-hours total.
• The invite text, ready to send or booked (if authorised).

Checks before you finish

• Every time shown was computed with zoneinfo, not by hand.
• Weekday and date are shown in each person's local time; a date change across the date line is called out.
• No option falls on a public holiday or weekend for a required attendee.
• Daylight-saving changes in the window were checked, and recurring series were checked on both sides of any change.
• Busy times from calendars were respected.
• Nothing was booked or sent to external people without the owner's go-ahead.

Pitfalls

• Using EST, CST, IST and similar. IST means India, Ireland or Israel depending on who you ask. Use IANA names.
• Assuming the offset is fixed. It changes twice a year in many places, on different dates.
• Forgetting the date line. Monday afternoon in New York is Tuesday morning in Sydney.
• Always sacrificing the same person. Rotate for recurring meetings.
• Offering only one slot. Give three real choices.
• Ignoring local holidays and different weekends. Check the official list for each country.

See also

• resource-capacity-planning, project-plan-and-timeline.