For most features, the three major calendar tools — Google Calendar, Microsoft Outlook, and Apple Calendar — are interchangeable. They all do meeting invites, recurrence, reminders, sharing. But for one feature, they diverge in ways that catch distributed teams out repeatedly: how each tool handles time zones. The defaults are different, the surface area for explicit zone control is different, and the failure modes when DST drifts under a recurring meeting are different. This post is a practical comparison focused only on the time-zone behaviour, written so you can pick the tool that fits your team and configure it correctly from the start.
We will walk through each tool's core behaviour, then summarize in a comparison table at the end, then close with the configuration changes most distributed teams should make on day one.
Google Calendar
Google Calendar treats time zones as a first-class concept. Every event has an associated time zone, set at creation time and stored alongside the event. The default zone is whatever is configured in Settings → General → Time zone; the calendar can also display a secondary zone in the day/week views, which is the single most useful feature for cross-region scheduling.
When you create a meeting, the time-zone selector is hidden behind a small link next to the time field — easy to miss. If you click it, you can set the start and end zones independently (useful for travel: a flight from JFK to LAX can be entered in America/New_York for the start and America/Los_Angeles for the end, and the calendar will compute the correct duration). For recurring meetings, the storage zone is whichever one was selected at creation; subsequent edits do not change the storage zone unless you explicitly do so.
Where Google Calendar surprises people: all-day events are stored as floating dates with no zone, so a "Holiday: Memorial Day" event will display on the same calendar date in every zone, even though the underlying holiday is geographically specific. This is correct behaviour for most all-day events, but it means you cannot use an all-day event to communicate "this whole day is a US holiday" to a team that includes Australia — the Australian colleague's calendar will show the all-day event on what is, for them, a normal workday.
Google Calendar's DST handling is rule-based: it stores the IANA zone identifier with each event and resolves the offset at display time. Recurring meetings created in America/Los_Angeles automatically follow Pacific Time's spring-forward and fall-back rules; the meeting stays at "09:00 PT" year-round. For attendees in other zones, the wall-clock time shifts during DST shoulders, exactly as covered in our post on DST and meeting planning.
Microsoft Outlook (Microsoft 365 / Exchange)
Outlook's time-zone story depends on which Outlook you mean. The desktop client (Windows or Mac), the web client (OWA, now called Outlook on the web), and the mobile client all behave slightly differently, which is the first surprise.
The Windows desktop client supports up to three time zones in the calendar grid: a primary, plus two additional. They appear as columns next to the time axis. The setting is in File → Options → Calendar → Time zones. This is genuinely useful: a project manager scheduling US ↔ Europe meetings can see Pacific, Eastern, and Central European time simultaneously when picking a slot.
When you create a meeting, the time-zone selector is more visible than Google's: there is a "Time zones" toggle in the meeting dialog that exposes start-zone and end-zone selectors. Outlook stores meetings in UTC under the hood, but the displayed zone for an event is the one selected at creation time. Editing the meeting from a different zone preserves the original zone unless you explicitly change it.
The web client (OWA) has caught up to most desktop features but the multi-zone calendar grid is more limited. The mobile clients show a single zone (the device's current zone) and cannot display secondary zones at all. For travelers, this means the iOS Outlook app and the desktop Outlook can show different times for the same meeting if the desktop and the device are in different zones — confusing the first time it happens.
Outlook's DST handling is correct but historically buggy. The Exchange server stores meetings in UTC plus an explicit zone identifier; clients translate at display time. The historical bug — "where did my meeting go on the Monday after spring forward?" — has been fixed for years but still surfaces occasionally when an account moves between Exchange Online and on-premises Exchange. If you see DST anomalies, the first debug step is to confirm both endpoints are running current Exchange and Outlook builds.
Apple Calendar (iCloud)
Apple Calendar's time-zone support is opinionated: it is off by default. Out of the box, every event is stored as "floating local time" — the same wall-clock time in whatever zone the device is currently set to. This is sometimes useful (your 7am workout stays at 7am wherever you travel) and sometimes catastrophic (your 9am Tuesday meeting with London moves with you to Tokyo).
To turn on time-zone support: System Settings → General → Date & Time → Set time zone automatically (this is unrelated, leave it on), then in Calendar app: Calendar → Settings → Advanced → Turn on time zone support. Once enabled, every new event has an explicit zone, and the meeting time stays anchored to that zone regardless of where the device is. Existing events created before the toggle was flipped remain floating, which is a footgun that bites people who travel and forget to enable the setting until after they have made a few meetings.
iCloud sync respects whatever the event was created with. A floating event syncs as floating; a zoned event syncs with its zone. This means a single calendar can contain a mix of floating and zoned events, and there is no obvious UI signal in the day or week view distinguishing them.
Apple Calendar can subscribe to remote calendars (Google, Exchange) via CalDAV or Exchange protocols. When it does, it inherits the source's time-zone behaviour: a Google-hosted event subscribed via Apple Calendar still has its IANA zone, and the display in Apple Calendar respects it. This is the right answer for most distributed teams: store the canonical calendar in Google or Exchange, and use Apple Calendar as a viewer with its own time-zone-support setting on.
Comparison table
| Feature | Google Calendar | Outlook (M365) | Apple Calendar |
|---|---|---|---|
| Default time-zone behaviour | Zoned (uses account zone) | Zoned (uses device zone) | Floating (until you opt in) |
| Per-event zone selector | Yes, slightly hidden | Yes, prominent | Yes, only after opt-in |
| Multi-zone calendar grid | 1 secondary zone | Up to 3 zones (Windows desktop) | No |
| Different start / end zones | Yes | Yes | Limited |
| All-day events behave as | Floating (no zone) | Floating (no zone) | Floating (no zone) |
| DST handling | Rule-based, IANA | UTC + zone identifier | Inherits source for synced calendars |
| Mobile parity with desktop | Good | Mobile loses multi-zone view | Good (floating gotcha applies) |
Day-one configuration for distributed teams
Whichever tool you pick, three changes are worth making before you create any recurring meetings.
- Turn on a secondary zone in the calendar grid view, set to the zone of your most-distant teammate. Google: secondary zone in Settings. Outlook desktop: up to two additional zones in Calendar options. Apple: not available — use a desktop calendar instead for cross-zone scheduling.
- Make the per-event zone selector visible by default if your tool supports it. In Google, the time-zone link is hidden until clicked; train yourself or your team to expand it before setting any cross-region meeting.
- For Apple Calendar users on a cross-region team, turn on time-zone support immediately. Then audit existing recurring events for floating zones — anything created before the toggle was flipped will need to be edited and re-saved with an explicit zone.
What about Notion Calendar, Fantastical, and others?
Most third-party calendar UIs (Notion Calendar, Fantastical, BusyCal) are clients on top of Google or iCloud, so they inherit the underlying tool's time-zone semantics. The differences live in the UI: Fantastical, for example, has the cleanest multi-zone meeting picker we have used; Notion Calendar prioritizes integration with Notion docs over time-zone tooling. None of these clients introduce new failure modes; they just expose the underlying calendar's behaviour through a different interface.
The wider point
None of the three major tools are wrong. They make different default trade-offs because their default user is different — Google for cross-org collaboration, Outlook for enterprise scheduling, Apple for personal use. For distributed teams, the right choice is whichever your team already standardises on, configured for explicit zones with a secondary-zone display turned on. The tool is rarely the bottleneck; the configuration is.
Where the calendar tool stops being enough is when you need to find a meeting window across more than two zones — none of the three has a satisfying multi-region overlap finder. That is where TimeZoneMeet's Schedule tool fits in, and the popular city pairs reference covers the slots we get asked about most often.
Further reading
- DST and meeting planning — the underlying mechanics that calendar tools navigate for you.
- Scheduling meetings across time zones without the headache — the habits that make any calendar tool work.
- Coordinating four-region all-hands meetings — when the multi-zone calendar grid is not enough.
- UTC offsets explained