Why not just use GMT instead of UTC?

GMT is a time zone that changes with daylight saving in the UK. UTC is a fixed timescale that never changes. For practical scheduling, they are the same when the UK is on standard time, but using UTC avoids the BST/GMT confusion entirely.

What if my team refuses to use 24-hour time?

The 24-hour clock eliminates AM/PM errors. If a team member insists on 12-hour format, write "14:00 (2:00 PM)" but keep the UTC time in 24-hour format as the primary reference. The key is consistency for the UTC value.

How do I handle a team where some members work flexible hours and don't have fixed time zones?

Ask them to state their working hours in UTC. "I work 08:00 to 16:00 UTC" is clear regardless of where they are physically located. Then schedule sessions within that UTC window.

Does UTC affect how I set up my computer's clock?

Set your computer's system clock to UTC and let the operating system handle local time display. This is standard practice for servers and recommended for anyone who works across time zones. Your calendar app will convert correctly.

What happens when a participant is in a location that does not observe DST at all?

Some locations like Singapore (UTC+8) and Mumbai (UTC+5:30) never change. Their offset is constant. That makes them easier to schedule with UTC because the offset does not need to be checked for DST changes.

UTC for Remote Teams: The Key to Global Meeting Scheduling

State every event time in UTC first. Then add local times for each participant. That one rule ends the "what time is it for me?" thread forever.

Why UTC Ends the Remote Scheduling Tangle

A sprint review needs three people: one in Singapore (UTC+8), one in London, one in New York. The London colleague opens their planner, sees a block of morning slots, and fires off "Let's do 10 AM." The New Yorker reads it on the subway, assumes Eastern, and blocks 15:00. The Singapore colleague sees the thread at dinner, converts from London time, and realises the proposed slot is 18:00 their time: doable, but tight. Then someone asks "wait, is London on GMT or BST right now?" Three more messages. The slot collapses.

UTC kills that loop because it never moves. It does not observe daylight saving time. Its offset stays UTC+0 in January, in July, and every month between. When you write "14:00 UTC", every person converts from the same fixed point. No one guesses whose local time you meant.

The common error: the organiser states the time in their own zone. A manager in Chicago sends "Let's connect at 10 AM." The colleague in Berlin assumes 10 AM Central Time, adds 7 hours, and arrives at 17:00 Berlin time. But the manager meant 10 AM Chicago time in summer, when Chicago sits at UTC-5. Berlin should have added 6 hours, not 7. The Berlin colleague misses the first 20 minutes. This happens daily in distributed teams.

State the event time in UTC plus local times for all participants. "14:00 UTC (15:00 Paris, 09:00 New York, 21:00 Singapore)." Everyone sees their own conversion confirmed in writing.

Put the UTC Time First in Every Invite

Lead with UTC in the subject line and the body. Not buried in the notes. Not an afterthought. First.

Why it works: UTC is the only reference that means the same thing to every person in the thread. "10 AM" is ambiguous. "10 AM ET" is ambiguous in October because the US might be on Eastern Daylight Time (UTC-4) or Eastern Standard Time (UTC-5) depending on the date. "14:00 UTC" is not ambiguous. It is 14:00 at the prime meridian, always.

Use the 24-hour clock. 14:00 is unambiguous. 2:00 PM requires the reader to notice the "PM" and not confuse it with 2:00 AM. In international teams, some members are native 24-hour clock users, some are not. Default to the format that eliminates the AM/PM confusion entirely.

What to write in the invite:

Subject: "Sprint review, 14:00 UTC (15:00 CET, 09:00 EST, 22:00 SGT)"

Body: "This session is at 14:00 UTC. Your local time: 15:00 Paris, 09:00 New York, 22:00 Singapore. Please confirm you can attend."

That is it. No spreadsheet. No "please convert yourself." No "what time zone does the organiser use?"

Convert UTC to Everyone's Local Time in Three Steps

You need each participant's UTC offset for the specific date of the gathering. Offsets shift with daylight saving time. The offset you used in January may be wrong in July.

Example from the reference data:

On 15 January 2026, New York sits at UTC-5. On 15 July 2026, New York sits at UTC-4. If you schedule a January call for July, you cannot use the January offset.

Conversion steps:

Find the UTC offset for each location on the exact date.
Add that offset to the UTC time. If the offset is negative, subtract.
Check the result: above 24 means the next calendar day for that person. Below 0 means the previous day.

Worked example: A session at 14:00 UTC on 15 July 2026. - New York: UTC-4. 14:00 minus 4 hours = 10:00 AM EDT. - London: UTC+1. 14:00 plus 1 hour = 15:00 BST. - Singapore: UTC+8. 14:00 plus 8 hours = 22:00 SGT.

All three participants see the same UTC time and calculate their local time from it. No one guesses.

Use the UTC Converter to check any date and location combination.

Three Scheduling Mistakes UTC Prevents

Mistake 1: The organiser states only their own zone.

A project lead in Los Angeles sends "Catch-up at 10 AM tomorrow." The developer in Mumbai sees the message at 8 PM IST, assumes 10 AM Los Angeles time, adds 13.5 hours, and calculates 11:30 PM IST. But it is July, so Los Angeles is on Pacific Daylight Time (UTC-7). The correct conversion: 10 AM PDT is 17:00 UTC, which is 22:30 IST. The developer misses the call by 11 hours.

Fix: Always write the UTC time first. "Catch-up at 17:00 UTC (10:00 Los Angeles, 22:30 Mumbai)."

Mistake 2: Abbreviations that mean three different things.

"CST" can mean Central Standard Time (UTC-6), China Standard Time (UTC+8), or Cuba Standard Time (UTC-5). "BST" can mean British Summer Time (UTC+1) or Bangladesh Standard Time (UTC+6). An abbreviation without a date or offset is a trap.

Fix: Write the UTC offset explicitly. "UTC+8" is not ambiguous.

Mistake 3: Assuming DST changes on the same date everywhere.

The United States moves to daylight time on the second Sunday in March. Europe moves on the last Sunday in March. For three weeks, New York sits at UTC-4 while London stays on GMT (UTC+0). A call set for 15:00 UTC is 11:00 AM in New York but 3:00 PM in London. If you assumed both were on standard time, you would be off by one hour for New York.

Fix: UTC does not change. The local offsets do. Check the offset for each location on the exact date, not a rule of thumb.

Set Your Planner to UTC and Let It Do the Work

Most calendar tools let you pin an event to UTC and display it in each attendee's local zone.

Google Calendar: Create the event with the time zone set to "UTC." Add attendees. They see the event in their own zone.
Outlook: When creating the event, set the start time zone to "UTC." Outlook shows the UTC time and each attendee's local equivalent.
World Clock planners: Input UTC as the reference, add locations, and see all local times side by side.

UTC Time Zone Converters give you a quick reference for any offset combination.

Write Down the Team Rules

A rule in writing stops the arguments before they start.

What to document:

"All recurring session times are stated in UTC in the title and the calendar entry."
"When sending an ad-hoc request, include the UTC time and the local time for each participant."
"Use 24-hour clock for all UTC times."
"Check UTC offsets for each participant on the exact date. Do not assume last month's offsets still apply."

Who enforces it: The person who sends the invite provides the correct UTC time. If they are unsure, they ask. "I am in Tokyo. The session is at 09:00 UTC. What is that in Tokyo time?" That question is easy to answer. "What is your time zone?" is not.

Handle DST Changes Without Breaking the Schedule

This is the hardest part of global scheduling. UTC solves it because UTC is the fixed reference. The local offsets move; UTC does not.

The problem: In March 2026, the US switches to daylight time on 8 March. Europe switches on 29 March. For three weeks, New York (UTC-4) is one hour closer to London (UTC+0) than it was in February. A 15:00 UTC gathering in February was 10:00 AM New York and 3:00 PM London. In late March, that same 15:00 UTC slot is 11:00 AM New York and 4:00 PM London (BST). If you did not update the invite, New York arrives an hour early.

The fix with UTC: The UTC time stays 15:00. The local conversion changes. Your calendar tool should handle this if each attendee's zone is set correctly. If you send manual invitations, recompute the local times for each date.

Rule of thumb: On the day of a DST change in a participant's location, verify their UTC offset. Do not trust a three-month-old calendar entry.

Template: UTC Invite for Global Teams

Copy this. Fill in the blanks.

Subject: [Session name], [UTC time] ([local time 1], [local time 2], [local time 3])

Body:

This session is at [UTC time in 24-hour format].

Your local times: - [Location 1]: [local time] ([UTC offset]) - [Location 2]: [local time] ([UTC offset]) - [Location 3]: [local time] ([UTC offset])

If you are in a location not listed, convert from UTC using a UTC converter.

Please confirm attendance. If the time does not work for your zone, reply with your available UTC windows.

Example:

Subject: Product sync, 14:00 UTC (15:00 Paris, 09:00 New York, 22:00 Singapore)

Body:

This session is at 14:00 UTC.

Your local times: - Paris: 15:00 CEST (UTC+2) - New York: 09:00 EDT (UTC-4) - Singapore: 22:00 SGT (UTC+8)

If you are in a location not listed, convert from UTC using a UTC converter.

Please confirm attendance. If the time does not work for your zone, reply with your available UTC windows.

That template eliminates the "what time is it for me?" question. Every participant sees their own time confirmed in writing.

Use UTC When You Travel Across Zones

UTC is not just for calls. If you travel across time zones for work, UTC is your reference for planning rest, sleep, and flight connections.

Jet lag severity correlates with the number of time zones crossed. Eastward travel (UTC offset increasing, New York to London) is harder to adjust to than westward travel. The body's circadian rhythm shifts about one hour per day. Crossing five time zones eastward means roughly five days to adjust. UTC gives you a fixed reference: your body is still on your home UTC offset. Fly from New York (UTC-5) to Paris (UTC+1) and you cross six time zones. Your body is six hours behind local time. Knowing that tells you when to seek light, when to avoid it, and when to sleep.

Flight plans are filed in UTC regardless of departure or arrival locations. A flight leaving Singapore at 23:00 local time (15:00 UTC) and arriving in London at 05:00 local time (04:00 UTC) has a UTC duration of 13 hours. Long-haul flight crew use UTC for rest-period calculations. They do not think in local time during the flight. They think in UTC.

What to do: Set your phone to show UTC as a second time zone. When you land, check the local time and your UTC offset. Your body's internal clock is still on your home UTC offset. Plan meals and sleep around UTC, not local time, for the first two days.

Quick Reference: UTC Scheduling Checklist

Keep this. Use it for every gathering with participants in more than one time zone.

[ ] State the time in UTC first (24-hour format).
[ ] List local times for all participants with their UTC offsets.
[ ] Check the UTC offset for each location on the exact date.
[ ] Confirm that DST changes between now and the date do not affect the offsets.
[ ] Set the calendar event time zone to UTC.
[ ] Include the UTC time in the event title.
[ ] Verify that each participant can convert from UTC to their local time (or provide a tool link).