How are timezones detected?

Via IANA timezone identifiers. We use the browser's Intl API plus a curated city → timezone map for one-click adding.

Yes — we use real IANA data, so spring-forward / fall-back is handled correctly even for cross-DST meetings.

Does my roster leave my browser?

No. Rosters live in your browser. Saved rosters sync to the cloud only when you opt in (Pro).

Do I get a free trial?

No — this is a paid tool with plans from $5 a month. Starter is $5/mo and Pro is $15/mo; you can cancel any time.

Account page or email. Cancellation stops next renewal.

Does the invite update automatically for DST changes?

Yes, if you anchor the meeting time to UTC, calendar apps automatically adjust the displayed local time for each attendee based on their current Daylight Saving Time rules. This ensures the meeting remains at the correct absolute moment without requiring manual updates when clocks shift.

How do I check if everyone is awake at the proposed time?

You must manually verify that the chosen UTC slot falls within reasonable working hours for all key participants, as automatic conversion does not guarantee convenience. It depends on the specific geographic spread of your team, so check the resulting local times for outliers like early mornings or late nights before sending.

Can I see all team members' local times at once?

Yes, by using a scheduling tool that displays a horizontal timeline or by listing the converted times directly in the invite description. This allows you to visually compare overlapping working hours across different regions in a single view without switching between calendars.

What happens if I forget to set the timezone?

Attendees will interpret the time based on their own local settings, which often leads to missed meetings if participants are in different regions. Without a specific timezone identifier, the invite lacks a fixed reference point, causing confusion about whether the time refers to the sender's or receiver's clock.

How to Change Time Zone in Meeting Invite

Learn how to set the correct timezone in meeting invites for remote teams to avoid confusion and ensure everyone attends at the right hour.

To change the time zone in a meeting invite, set the meeting time using a universal reference like UTC or Coordinated Universal Time, then let each attendee’s calendar app convert it to their local time automatically. This prevents confusion because the underlying timestamp remains constant regardless of where the viewer is located.

Why timezone errors happen in invites

Most scheduling confusion stems from ambiguous time formats. When you write "Meet at 9:00," the recipient must guess whether you mean their local 9:00 AM or your local 9:00 AM. If you are in different time zones, these are different moments. Using a specific time zone identifier removes this guesswork. It ensures that everyone sees the same absolute moment on their screen, adjusted correctly for their location. This is especially critical for remote teams spanning multiple continents, where a one-hour difference can mean the difference between a morning meeting and a late-night interruption.

Step-by-step: Setting the correct timezone

The most reliable method is to anchor your invite to UTC. This standard is stable and recognized by all major calendar systems. Here is how to apply this approach using a realistic scenario.

Imagine a distributed team with members in London, New York, and Tokyo. They need a 30-minute sync. You choose 14:00 UTC as the anchor time. When you create the invite, you enter this exact time. Each attendee’s calendar software then converts this UTC timestamp into their local time zone.

Here is how that single invite appears to each person:

Location	Local Time Display	Reason
London	15:00 BST	London is UTC+1 during British Summer Time.
New York	09:00 EST	New York is UTC-5 during Eastern Standard Time.
Tokyo	23:00 JST	Tokyo is UTC+9 year-round.

Notice that Tokyo’s attendee sees a late-evening slot. This is a valid outcome, but it highlights why choosing the right UTC hour matters. If you had chosen 09:00 UTC, London would see 10:00, New York would see 04:00, and Tokyo would see 18:00. The goal is to find a UTC slot where everyone’s local time falls within reasonable working hours. You do not manually convert times for each person; you set the UTC anchor once, and the system handles the rest.

Handling DST and cross-region conflicts

Daylight Saving Time (DST) changes can shift the relationship between time zones. For example, when Europe shifts clocks forward, the time difference between London and New York changes from four hours to five hours. If you hard-code a time difference like "London is always five hours ahead of New York," your invite will be wrong twice a year.

Using UTC avoids this problem because UTC does not observe DST. It remains constant. When a calendar app reads "14:00 UTC," it calculates the correct local offset for that specific date, accounting for DST rules active on that day. This ensures accuracy even during transition weeks when offsets are shifting. Always prefer the UTC anchor over relative offsets like "GMT+1" if you want consistent behavior across seasons.

Using shareable links for clarity

If your team frequently struggles with manual conversions, shareable links offer a cleaner alternative. Instead of sending a static text invite, you provide a link that renders the meeting time dynamically for each viewer. When an attendee clicks the link, their browser detects their local time zone and displays the meeting time accordingly. This eliminates the need for the attendee to calculate offsets mentally.

Tools like TimeForge specialize in this workflow by allowing you to pick teammates' time zones and find overlapping working hours. Once you identify a suitable slot, you generate a link that shows the same chart in every viewer's local timezone. This ensures everyone sees the correct start time without needing to interpret UTC conversions themselves. It reduces back-and-forth emails asking, "Is this my time or yours?"

Best practices for distributed teams

Consistency is key to avoiding scheduling friction. Establish a standard format for your invites. Start with the UTC time, followed by the local times for your core hubs. For example: "Sync Meeting: 14:00 UTC (London 15:00, NY 09:00, Tokyo 23:00)." This redundancy helps if someone’s calendar fails to auto-convert correctly.

Check the overlap before sending. A quick mental check or a tool that highlights working-hour overlaps can prevent booking meetings at inconvenient hours. For instance, ensure the chosen UTC slot does not fall in the middle of the night for your most remote teammate. If a conflict arises, adjust the UTC anchor rather than asking individuals to change their calendars.

Finally, keep your team roster updated. If someone moves to a new city, update their time zone preference in your scheduling tools. This ensures future invites reflect their current location automatically. By anchoring to UTC and leveraging dynamic display tools, you create a scheduling system that respects everyone’s local context without requiring manual calculation for every invite.