Source: https://cli.nylas.com/guides/schedule-across-timezones-cli

# Schedule Meetings Across Time Zones (CLI)

Picking a meeting time for people in New York, London, and Tokyo is the kind of arithmetic that's easy to get wrong by an hour — especially around a daylight-saving change. The Nylas CLI does the timezone math for you, entirely offline: convert a time between zones, find a slot that overlaps everyone's working hours, check for DST transitions, then book it in the calendar. Here's the full flow from 'when works' to a booked event.

Written by [Aaron de Mello](https://cli.nylas.com/authors/aaron-de-mello) Senior Engineering Manager

Updated June 8, 2026

> **TL;DR:** `nylas timezone find-meeting --zones "America/New_York,Europe/London,Asia/Tokyo" --duration 1h` returns slots that overlap everyone's working hours — computed offline, no API call. `timezone convert` translates a single time, `timezone dst` warns about daylight-saving shifts, and `calendar events create --lock-timezone` books the result so it displays correctly for every attendee.

Command references used in this guide: [`nylas timezone find-meeting`](https://cli.nylas.com/docs/commands/timezone-find-meeting), [`nylas timezone convert`](https://cli.nylas.com/docs/commands/timezone-convert), and [`nylas calendar events create`](https://cli.nylas.com/docs/commands/calendar-events-create).

## How do you find a meeting time across time zones?

The `nylas timezone find-meeting` command takes a comma-separated list of IANA zones and a duration, then returns the time windows where everyone's working hours overlap. It runs entirely offline against the IANA time zone database, so there's no API call and no calendar connection needed just to answer “when can we all meet.” For three zones spanning 14 hours, it surfaces the narrow overlap most people compute wrong by hand.

Zone names come from the [IANA time zone database](https://www.iana.org/time-zones) — `America/New_York`, not “EST” — because only the IANA identifier encodes the DST rules correctly. The command returns each candidate slot rendered in every participant's local time, so you see exactly what each person's invite will read before you send anything.

```bash
# Find slots that work for New York, London, and Tokyo
nylas timezone find-meeting \
  --zones "America/New_York,Europe/London,Asia/Tokyo" \
  --duration 1h
```

## How do you convert a single time between zones?

When you already have a proposed time and just need it in another zone, `nylas timezone convert` translates it. Pass the source and target zones, and it prints the equivalent local time, accounting for the current DST state of each. This is the one-off version of the math: “3pm Pacific is what in Kolkata?” answered without a browser tab.

```bash
# Convert a meeting time from Pacific to India Standard Time
nylas timezone convert \
  --from America/Los_Angeles \
  --to Asia/Kolkata
```

## How do you avoid daylight-saving mistakes?

Daylight-saving changes are where cross-zone scheduling quietly breaks: a recurring 9am call can drift by an hour for some attendees when one region springs forward and another doesn't. The `nylas timezone dst` command lists a zone's DST transitions for a year, so you can check whether your meeting date falls near a shift before you commit to it.

The trap is that not all regions change on the same date, and some don't change at all — the US, EU, and Australia all transition on different days, and most of Asia observes no DST. The IANA database tracks every one of these rules, and so does `timezone dst`, which is why checking the transition beats trusting a fixed UTC offset. The procedures for maintaining that data are set out in [RFC 6557](https://www.rfc-editor.org/rfc/rfc6557).

```bash
# Check New York's DST transitions for 2026 before scheduling near one
nylas timezone dst --zone America/New_York --year 2026
```

## How do you book the meeting in everyone's calendar?

Once you've picked a slot, `nylas calendar events create` books it and invites attendees, and `--lock-timezone` pins the event to a specific zone so it always displays consistently rather than shifting with the viewer's settings. Add each attendee with a repeated `--participant` flag; the invite sends from your connected account across whichever calendar provider you use.

Because event times follow the iCalendar standard ([RFC 5545](https://www.rfc-editor.org/rfc/rfc5545)), each provider renders the locked time correctly in the recipient's own client. That closes the loop: find the slot offline, then commit it to real calendars. For availability checks against connected calendars, see [check calendar availability](https://cli.nylas.com/guides/check-calendar-availability-cli).

```bash
# Book the chosen slot, locked to a zone, with attendees
nylas calendar events create \
  --title "Global sync" \
  --start "2026-06-10 08:00" --end "2026-06-10 09:00" \
  --lock-timezone \
  --participant ny@example.com \
  --participant london@example.com \
  --participant tokyo@example.com
```

## Next steps

- [Check calendar availability](https://cli.nylas.com/guides/check-calendar-availability-cli) — free/busy across connected calendars
- [Create calendar invites](https://cli.nylas.com/guides/create-calendar-invites-cli) — events and attendees from the terminal
- [Manage your calendar from the terminal](https://cli.nylas.com/guides/manage-calendar-from-terminal) — events across providers
- [Recurring events and RRULE](https://cli.nylas.com/guides/recurring-calendar-events-api) — repeating meetings and DST
- [Full command reference](https://cli.nylas.com/docs/commands) — every flag and subcommand documented