Should you schedule in UTC?

"Should I just put everything in UTC?" is a fair instinct. UTC never drifts, never has a summer version, and gives everyone one shared number. But a shared number nobody lives in can be worse than no number at all. The right choice depends on who is reading.

When UTC is the right reference

UTC earns its place when the time has to be unambiguous to a wide or technical audience, and when readers are comfortable converting it themselves:

• Engineering and operations. Logs, incidents, deploy windows and on-call rotations are all written in UTC so a server in Frankfurt and an engineer in Sydney read the same timestamp.
• Software and product schedules. A release going live at "09:00 UTC" is clearer than naming one city's clock, because no reader has to guess whose morning you meant.
• Broad announcements. A webinar or maintenance notice reaching hundreds of people across dozens of zones is cleanest with one anchor that everyone can convert from.

In each case the audience expects UTC and knows how to translate it. The shared standard is doing real work.

When local time is clearer

For most everyday invites, the opposite is true. Nobody mentally lives in UTC. A 1:1, a small team sync or a sales call between a handful of named people reads far more naturally in each person's own clock. This is the common case: in Buffer's 2023 State of Remote Work report, 62% of respondents said people on their immediate team were spread across multiple time zones. Writing "15:00 UTC" forces every recipient to do a conversion, and every conversion is a chance to land an hour off, or thirty minutes off for anyone in India or Iran.

If you are picking a time for three people in three cities, the kind thing is to do the maths once, for them, and hand over each local time directly.

The best of both: state UTC plus local

You rarely have to choose. The most robust way to write any cross-zone time is to pick one anchor and list its local equivalents, with the date attached to each:

The UTC line gives a fixed reference anyone can verify. The local lines remove the conversion for the people who actually need to show up. Notice Sydney lands on the following day, which is exactly the kind of slip a plain "14:00 UTC" hides.

A few rules that hold up

1. Use 24-hour or always add AM/PM. "7:30" is two different times twelve hours apart. Be explicit.
2. Attach the date to every time. An evening in one zone is the next morning in another, as the Sydney row shows.
3. Prefer UTC over GMT in writing. It removes the summer ambiguity entirely.
4. Name cities, not just offsets. "New York" survives daylight saving changes; "UTC-5" quietly becomes wrong in summer.

For more on phrasing a time so it cannot be misread, see how to write a meeting time in an email.

Letting the tool do the conversion

The reason these mistakes persist is that people convert by hand under time pressure. The fix is to never convert at all. Atlas pins each teammate or city on a world map and shows their current local time, shades their working hours, and suggests the best overlapping slot. When you pick one, it adds the meeting to your calendar in everyone's correct local time, with daylight saving already handled, so the UTC-versus-local question simply stops being yours to get wrong.