How Daylight Saving Time Affects International Meetings

Daylight Saving Time can change the time difference between two countries by one hour, even when only one of them changes its clocks. This is why a recurring international meeting that normally appears at 9:00 AM for one person and 6:30 PM for another can suddenly move to 7:30 PM, even though nobody edited the meeting.

The main reason is simple: UTC offsets change seasonally in some locations, but not in others.

For example, New York changes between EST = UTC-05:00 and EDT = UTC-04:00. India stays on IST = UTC+05:30. So the New York to India difference changes from 10 hours 30 minutes to 9 hours 30 minutes without India changing its clock at all.

For date-specific conversions, use the CurrentDateTime Time Zone Converter rather than relying on a memorized time difference.

Why DST Causes Meeting Times to Move

A recurring meeting can be anchored in one location's local time.

Suppose a weekly meeting is scheduled for: 9:00 AM New York time.

During Eastern Daylight Time: New York = UTC-04:00.
During Eastern Standard Time: New York = UTC-05:00.

The meeting stays at 9:00 AM in New York. But its UTC time changes. During EDT: 9:00 AM New York = 13:00 UTC. During EST: 9:00 AM New York = 14:00 UTC.

Anyone in a country that does not make the same clock change sees the meeting move by one hour. That is not a calendar malfunction. It is the expected result of changing UTC offsets.

DST Does Not Happen Everywhere

A major source of international scheduling errors is assuming every country observes Daylight Saving Time. They do not. Some countries change clocks seasonally. Others stay on one offset all year.

For example:

• India stays on UTC+05:30
• Pakistan stays on UTC+05:00
• Japan stays on UTC+09:00

while many locations in the United States and Europe change seasonally. This means meetings between a DST-observing location and a non-DST location often shift by one hour during the year.

The United States and Europe Do Not Change Clocks on the Same Dates

This is one of the most important international scheduling problems. The United States and Europe both use seasonal clock changes in many locations, but their transition dates are not identical.

In 2026, participating U.S. locations began Daylight Saving Time on: March 8, 2026, while the United Kingdom and EU countries moved to summer time on: March 29, 2026. NIST confirms the U.S. transition date, while GOV.UK and the European Commission confirm the European schedule.

This creates several weeks when normal U.S.-Europe time differences are temporarily different.

Example: New York and London

For much of the year, New York and London are five hours apart.

During a normal summer period: New York = EDT = UTC-04:00, London = BST = UTC+01:00. Difference: 5 hours.

But after New York changes clocks in March and before London changes: New York = EDT = UTC-04:00, London = GMT = UTC+00:00. Difference: 4 hours.

So a recurring call normally scheduled as: 9:00 AM New York / 2:00 PM London can temporarily appear as: 9:00 AM New York / 1:00 PM London for part of March. Once the UK enters BST, the five-hour difference returns.

The Autumn Creates Another DST Gap

The same problem happens in autumn. The UK and much of Europe return to standard time before the United States does.

In 2026, the UK and EU summer-time period ends on: October 25, while participating U.S. locations return to standard time on: November 1. During that gap, the usual U.S.-Europe relationship changes again. This is why international meetings can temporarily shift twice a year even when both locations observe DST.

Global City Pairings and Seasonal Shift Matrix

Why India Meetings Change Even Though India Has No DST

India stays on: UTC+05:30 throughout the year. New York changes between: UTC-05:00 and: UTC-04:00.

So:

• New York on EST: India is 10 hours 30 minutes ahead
• New York on EDT: India is 9 hours 30 minutes ahead

Suppose your recurring meeting stays at: 9:00 AM New York. During EDT: 6:30 PM India. During EST: 7:30 PM India. The Indian participant sees the one-hour shift even though India's clocks never moved.

The Same Problem Happens With Pakistan

Pakistan remains at: UTC+05:00. New York changes seasonally. During EDT: Pakistan is 9 hours ahead. During EST: Pakistan is 10 hours ahead.

A recurring: 9:00 AM New York meeting becomes: 6:00 PM Pakistan during EDT, and: 7:00 PM Pakistan during EST. Again, Pakistan did not change. New York did.

Europe and India Meetings Also Move

Germany, France, Italy, and many other Central European locations change between: CET = UTC+01:00 and: CEST = UTC+02:00. India remains: UTC+05:30.

So India is: 4 hours 30 minutes ahead of CET, but only: 3 hours 30 minutes ahead of CEST. A meeting fixed at: 10:00 AM Berlin can therefore appear at: 2:30 PM India during CET, and: 1:30 PM India during CEST.

UK and India Meetings Change Too

The UK alternates between: GMT = UTC+00:00 and: BST = UTC+01:00. India stays on: UTC+05:30.

So during GMT: India is 5 hours 30 minutes ahead. During BST: India is 4 hours 30 minutes ahead. A London meeting fixed at 10:00 AM therefore appears one hour earlier in India during British Summer Time.

DST Changes the Difference, Not Just the Clock

This distinction helps explain almost every international meeting problem.

Suppose: City A = UTC-05:00, City B = UTC+05:00. Difference: 10 hours. City A then moves to: UTC-04:00. City B stays at: UTC+05:00. New difference: 9 hours.

Nothing mysterious happened. The UTC offset of City A changed. The time difference is simply the distance between those two offsets.

Why Memorized Time Differences Fail

People often memorize relationships such as:

• "London is five hours ahead of New York."
• "India is 9.5 hours ahead of New York."
• "Berlin is six hours ahead of New York."

These can be true for part of the year. They are not necessarily true for every date. A safer rule is: city + date + timezone rules = correct difference, not: "city A is always X hours ahead of city B."

The Meeting Date Matters

Suppose you are scheduling: 9:00 AM New York for: February 10, and then another meeting at the same local time on: July 10. Those meetings may have different UTC offsets.

If the attendee is in a country without DST, their local time can differ by one hour between the two dates. This is why a timezone converter should ask for: date as well as: time and location.

Current Offset Is Not Enough for a Future Meeting

Another common mistake is searching: "What time is it in London right now?" and using today's difference for a meeting three months away. That works only if the timezone relationship is unchanged on the future date.

If a DST transition occurs between today and the meeting, the conversion may be wrong by an hour. Use the actual future date with the CurrentDateTime Time Zone Converter.

Why Recurring Meetings Are More Difficult Than One-Time Meetings

For one meeting, you only need to know the timezone rules on one date. For a weekly meeting lasting six months, the series may cross:

• U.S. spring DST
• European spring DST
• European autumn transition
• U.S. autumn transition

That means the local time shown to some participants can change several times. Recurring international meetings therefore need an explicit timezone strategy.

Decide Which Local Time Should Stay Fixed

Before creating a recurring meeting, ask: Whose local clock should remain unchanged?

Suppose the meeting is: 9:00 AM New York. If New York is the anchor, keep the event tied to: America/New_York. The U.S. participant continues to see: 9:00 AM. Other participants may see their local time shift.

If India should remain fixed instead, anchor it to: Asia/Kolkata. Then the U.S. local meeting may move.

Fixed Local Time vs Fixed UTC Time

These are not the same thing.

• Fixed New York local time: Meeting stays 9:00 AM New York. UTC changes between 13:00 during EDT and 14:00 during EST.
• Fixed UTC time: Meeting stays 14:00 UTC. New York sees 10:00 AM during EDT and 9:00 AM during EST.

Which method is correct depends on the meeting's purpose.

When UTC Is Useful

UTC works well when one global instant should remain fixed. Examples include: maintenance windows, server deployments, livestream launches, global release times, incident response, and technical operations.

For example: Maintenance begins at 18:00 UTC. That instant does not shift because New York enters DST. Each participant converts that UTC value into local time.

When Geographic Time Zones Are Better

For recurring human schedules, geographic time zones are usually more useful. Suppose: Team call every Tuesday at 9 AM New York time. Use: America/New_York, not: UTC-05:00.

Why? Because New York does not stay at UTC-05:00 all year. Its geographic timezone allows software to apply the correct seasonal rule automatically. The IANA Time Zone Database maintains these geographic timezone histories and rules.

Do Not Hard-Code EST for a Year-Round New York Meeting

EST means: UTC-05:00. EDT means: UTC-04:00. If you want the meeting to remain at 9:00 AM local New York time all year, neither fixed abbreviation works for the entire year.

Use: ET in human-facing text if appropriate. Use: America/New_York in software and calendars.

Do Not Hard-Code GMT for a Year-Round London Meeting

GMT means: UTC+00:00. BST means: UTC+01:00. If you schedule a summer London event as GMT when you really mean London local time, international attendees can be one hour wrong.

Use: Europe/London for recurring schedules. The same rule applies to CET and CEST.

Google Calendar Can Handle DST Automatically

Google Calendar supports event time zones and allows users to select a timezone using a city or region. Its official help documentation also allows users to display a secondary timezone.

For an international recurring meeting:

1. Create the event in the correct geographic timezone.
2. Add attendees.
3. Let their calendars convert the event into their local time.
4. Check how the meeting appears before and after DST transitions.

Do not manually create separate converted events.

Working Hours Still Matter After the Conversion

A calendar can tell you that: 8:00 AM New York = 5:30 PM India, but it cannot automatically decide whether 5:30 PM is acceptable for that person. Correct conversion and good scheduling are different tasks.

After converting, check: working hours, lunch periods, school or childcare constraints, religious or cultural schedules, local holidays, and whether a recurring evening meeting is sustainable. DST can turn a reasonable slot into a poor one overnight.

A Meeting Can Become Too Late After DST Ends

Suppose: 9:00 AM New York = 6:30 PM India during EDT. That might be acceptable. After New York returns to EST: 9:00 AM New York = 7:30 PM India. The same recurring meeting now pushes into the evening.

This is why teams should review recurring meetings around DST transitions rather than assuming calendars solving the math also solve the human problem.

Add DST Reviews to Your Team Calendar

For international teams, schedule a quick review before major clock changes. Ask:

• Which recurring meetings will move?
• Which participants do not observe DST?
• Will anyone's meeting move outside preferred work hours?
• Does the meeting need a new slot?
• Should inconvenience rotate?

This can prevent months of unnecessary scheduling friction.

Rotate Difficult Meeting Times

Some global teams have no perfect overlap. Suppose a meeting involves: California, India, and Europe. Someone may need an early morning or evening meeting.

If the meeting is recurring, avoid making the same region absorb the inconvenience forever. You might rotate: week 1 favors India, week 2 favors the U.S., and week 3 favors Europe. A rotating schedule can be fairer than a permanently inconvenient one.

Use Asynchronous Work When the Overlap Is Too Small

DST can shrink an already narrow overlap. Not every update needs a live meeting. Move routine information into: shared documents, project trackers, recorded walkthroughs, written status updates, and chat threads.

Use live overlap for discussions that actually benefit from real-time interaction. This is particularly helpful for U.S.-Asia teams.

Why a 30-Minute Time Zone Makes DST Calculations Look Stranger

Some countries use fractional offsets. India: UTC+05:30. Nepal: UTC+05:45. When a U.S. location changes by one hour, the resulting time difference may become something like: 9 hours 30 minutes or: 10 hours 30 minutes.

The half hour did not come from DST. It came from the other location's normal UTC offset. DST simply changes the whole-hour portion.

Example: New York and Nepal

Nepal is: UTC+05:45. New York on EDT: UTC-04:00. Difference: 9 hours 45 minutes. New York on EST: UTC-05:00. Difference: 10 hours 45 minutes. This is another reason manual mental conversions become risky quickly.

DST Can Change the Calendar Date Too

A one-hour shift sounds small, but meetings near midnight can move onto a different calendar date. Imagine a U.S. evening meeting that appears early the next morning in Asia. A DST change can move: 12:30 AM to: 1:30 AM, or potentially move a meeting across midnight in another configuration. Always check both: local time and: local date.

Travel Can Make Calendar Behavior Look Wrong

Suppose you create a meeting while living in New York, then travel to London. Your calendar may display the event in your current local timezone. The underlying event instant did not necessarily change. Only your display timezone changed.

When diagnosing an apparent meeting shift, check: event timezone, device timezone, participant timezone, DST status, and whether you are traveling.

Why Phones Usually Get DST Right

Modern phones and computers use maintained timezone data. They know that: America/New_York has seasonal rules. They do not simply store "New York = UTC-5 forever." That means automatic clock changes are normally handled without user intervention.

However, old devices, stale timezone databases, manual timezone settings, or custom software can still cause errors.

Time Zone Rules Can Change Politically

DST rules are created by governments. They are not laws of physics. Countries can: start observing DST, stop observing DST, change transition dates, or change UTC offsets. The IANA Time Zone Database is updated when political authorities make these changes. This is another reason not to hard-code future timezone rules permanently.

Why Calendar Software Needs IANA Zones

A geographic zone such as: America/New_York does more than say: UTC-5. It includes the historical and applicable rules for when New York moves between UTC-5 and UTC-4. Likewise: Europe/Berlin handles CET and CEST, and Europe/London handles GMT and BST. This makes IANA-style geographic zones essential for reliable recurring international scheduling.

What Happens During the Spring DST Transition?

When clocks move forward, one local hour disappears. In New York, the spring transition typically moves from: 1:59:59 AM to: 3:00:00 AM. The local times between: 2:00 AM and 2:59:59 AM do not occur on that date.

Scheduling a meeting in that missing hour can create problems depending on the calendar system. Avoid creating recurring events at DST transition hours unless you understand the platform's behavior.

What Happens During the Autumn Transition?

When clocks move backward, an hour repeats. A local: 1:30 AM may occur twice: once before the offset change and: once after it. Those are different instants.

For ordinary business meetings this rarely matters because most meetings happen during daytime. For: server jobs, overnight shifts, transportation, financial processing, and logging, it can matter a lot.

DST and Server Timestamps

Technical systems often store events in UTC or Unix time and convert them into local time later. That helps avoid ambiguity around missing and repeated hours. For epoch values, use the CurrentDateTime Unix Timestamp Converter. The timestamp identifies the instant; the timezone determines the local display.

Common DST Meeting Mistakes

A Reliable International Meeting Workflow

For every cross-border meeting:

The Rule to Remember

The simplest way to understand DST and international meetings is:

Daylight Saving Time changes UTC offsets, and changing UTC offsets change time differences.

That is why:

• a New York to India meeting can move by one hour
• a London to India meeting can move by one hour
• a Berlin to Japan meeting can move by one hour
• New York and London can temporarily be four hours apart instead of five
• U.S.-Europe meetings can shift even though both regions observe DST

Do not schedule international meetings from a memorized time difference.

Use: city + date + geographic timezone.

For one-time or future meetings, use the CurrentDateTime Time Zone Converter. For city-specific local time and UTC offsets, use the CurrentDateTime World Clock.

For recurring meetings, decide which location's local time should remain fixed and anchor the calendar event to that geographic timezone.

The goal is not just to get the conversion right once. It is to make sure the meeting stays correct when the clocks change.