A weekly international meeting can run perfectly for months and then, without anyone changing the calendar invitation, suddenly appear an hour earlier for one participant. A call that comfortably started at 4 p.m. may move into lunch. Another that used to begin at 9 a.m. may turn into an 8 a.m. start.
The usual explanation is daylight saving time, but that only describes part of what is happening.
The deeper problem is that international meetings are built on relationships between local clocks, and those relationships are not always fixed throughout the year. Some countries move their clocks forward in spring and back in autumn. Others leave them unchanged. Even among places that use seasonal clock changes, the dates do not always match.
As a result, “London is X hours ahead of us” can be true in January, wrong for several weeks in March, true again during summer, and change once more in autumn.
For companies working internationally, that creates a peculiar type of scheduling problem. Nothing about the meeting itself has changed. The people have not moved. The calendar may still show the same recurring event. What changed is the offset between the places where those people happen to be.
A meeting is tied to local time, not just a number on the clock
People usually remember time differences as simple arithmetic.
London is a certain number of hours ahead of another city. Italy is one hour ahead of London. Arizona is several hours behind Europe.
That approach works until one of the locations changes its clocks and another one does not.
London provides a useful example. During part of the year the United Kingdom uses Greenwich Mean Time, or GMT. During the warmer part of the year, clocks move forward and London operates on British Summer Time, or BST. Someone arranging calls with British colleagues may therefore find it safer to check the current time in London rather than assume that a remembered UTC difference applies all year.
Italy changes seasonally as well, moving between Central European Time and Central European Summer Time. Because the United Kingdom and EU countries currently coordinate the dates of these seasonal changes, the difference between London and Rome normally remains one hour even though both clocks move.
That distinction is important.
A clock change does not automatically change the time difference between two places. If both places change by the same amount at the same moment, their relationship stays intact. The real scheduling trouble begins when only one side changes, or when two sides change on different dates.
This is why daylight saving time becomes much more confusing in international business than it appears locally. Residents of one country simply notice that the clock has moved by an hour. A distributed team has to consider whether everyone else’s clock moved with it.
The calendar can be right while the meeting feels wrong
Modern calendar software handles time zones reasonably well. A properly configured meeting normally remains attached to a specific time zone and is converted automatically for participants elsewhere.
That prevents many obvious mistakes, but it does not solve the human problem.
Imagine a recurring call between teams in Europe and a region that does not change its clocks. For several months, the European team may join at 5 p.m. and the other team at 9 a.m. When Europe moves into summer time, the same recurring meeting can remain fixed at 9 a.m. for one side while appearing at 6 p.m. for the other.
Technically, nothing is broken. The software has converted the event correctly.
Operationally, however, the meeting has changed.
The new time may collide with school pickups, the end of the working day, another regular meeting or a period when customers are busiest. This is one reason recurring international meetings should not be treated as “set once and forget forever”.
Their UTC relationship may remain stable while their position inside somebody’s local working day moves.
The problem becomes more noticeable with large distributed teams. A one-hour shift that is harmless in one country can push another participant outside normal working hours. If a company has people in four or five regions, the effect becomes difficult to judge from memory alone.
Arizona shows why memorized time differences fail
Arizona is particularly useful for understanding the problem because most of the state does not observe daylight saving time. US federal rules allow states to exempt themselves from DST, and Arizona has chosen to do so. Most of the state therefore keeps Mountain Standard Time throughout the year.
This produces something that initially sounds contradictory: Arizona’s clock does not change, but Arizona’s time difference with many other places does.
Consider a company with employees in Phoenix and Europe.
When European countries move their clocks forward in spring, Phoenix stays where it is. The gap between the two locations changes by an hour. When Europe returns to standard time in autumn, the previous difference returns.
From the Arizona employee’s perspective, nothing happened locally. From the European employee’s perspective, the clocks changed normally. From the perspective of their recurring meeting, however, the relationship between their working days has shifted.
Someone coordinating calls with the state can therefore check the current time in Arizona instead of relying on a rule such as “Arizona is always X hours behind Europe”.
There is an additional local complication. Most of Arizona avoids daylight saving time, but the Navajo Nation observes it. That means even a statement such as “Arizona does not change clocks” needs a qualification.
For ordinary international business, Phoenix is usually the more relevant reference point, but the exception illustrates a broader lesson. Political borders, time-zone borders and daylight-saving rules do not always line up as neatly as people expect.
Europe is simpler internally, but not necessarily externally
Italy presents almost the opposite case.
Like other EU countries under the current system, Italy moves to summer time on the last Sunday in March and returns to standard time on the last Sunday in October. The EU has debated ending seasonal clock changes, but no final agreement has replaced the existing arrangement, so the twice-yearly system remains in place.
That coordination is valuable for business.
If Milan, Paris, Berlin and Madrid all change on the same schedule, a regular 10 a.m. meeting between those locations does not suddenly become 9 a.m. for one participant simply because summer time has started. Their shared offset remains stable.
The situation changes as soon as a company brings in a participant from somewhere following different rules.
A manager may know the current time in Italy and know the local time at a US office, but the difference between those two places can still depend on the date.
This is where international scheduling becomes counterintuitive. People tend to think in pairs of places, as though every pair has one permanent time difference. In reality, a pair can have one difference during most of the year and another during transitional periods.
The effect can be brief, but brief is enough to cause trouble.
A quarterly board meeting may fall exactly inside one of those weeks. So can a product launch, conference call, interview process or client presentation. People who have been using the same mental calculation for months suddenly arrive an hour early or late because the old calculation was correct until recently.
March and October are where assumptions break
The most error-prone periods are not necessarily the middle of summer or winter. They are the weeks surrounding clock changes.
When two regions follow different transition dates, there can be short periods during which their normal time difference changes before returning to the familiar pattern.
This is especially relevant for transatlantic work.
Someone may spend most of the year knowing exactly when colleagues start work abroad. Then the seasonal transition arrives and the relationship temporarily moves by an hour. Once the second region changes its clocks, the familiar difference returns.
Because the unusual period may last only a few weeks, people are less likely to build a new habit around it. They simply continue using the old calculation.
That makes transitional periods surprisingly good at producing calendar confusion.
The risk is higher when meetings are arranged outside calendar software. Messages such as “Let’s speak at 3 tomorrow” or “same time next Thursday” assume that both participants share the same understanding of what “same time” means.
For local colleagues, they usually do. For people separated by time zones and different daylight-saving schedules, they may not.
Recurring meetings deserve more attention than one-off calls
A one-time international meeting usually forces someone to check the time. A recurring meeting often does the opposite.
Once everyone has joined successfully for several weeks, the schedule feels settled. People stop thinking about the conversion.
That confidence is exactly why clock changes can be disruptive.
Suppose an international team agrees on a weekly meeting because 4 p.m. in one office corresponds neatly with the morning in another. The calendar invitation repeats for the rest of the year. Months later, a seasonal time change alters the local hour for one side.
Nobody has edited the meeting, yet the original reason for choosing that time may no longer apply.
Companies with heavily distributed teams can avoid much of this friction by reviewing recurring meetings around seasonal clock changes. The question is not whether the calendar converted the event correctly. The question is whether the resulting local times are still reasonable for everyone.
For a meeting involving three people, this takes seconds. For a company with teams scattered around the world, it can prevent months of one group quietly attending calls at an inconvenient hour.
“9 a.m. Eastern” is better than “9 a.m.”, but dates still matter
Clear time-zone labels help, but abbreviations can create their own problems.
People often use labels such as GMT, BST, CET, CEST, EST or EDT interchangeably with city-based time zones. They are not always interchangeable.
“London time” automatically reflects London’s seasonal rules. “GMT” refers to a specific offset. During British Summer Time, those are not the same thing.
Likewise, Italy is not permanently on CET. During summer time it uses CEST.
For software and automated systems, location-based time-zone identifiers are generally more robust because they can apply the relevant historical and seasonal rules for a particular date. For ordinary human communication, city names can also be clearer than expecting every participant to remember abbreviations.
“10:00 London time on April 8” communicates something different from simply writing “10:00 GMT”.
The date matters because a time zone is not merely a place. It is a set of rules applied at a particular moment.
The inconvenience is small until the meeting matters
Being an hour early for an informal internal call is annoying. Being an hour late for an interview, investor presentation or customer demo is a different matter.
International businesses depend on timing in ways that go well beyond meetings. Webinars open at specific hours. Support shifts hand over responsibility. Advertising campaigns launch on schedule. Logistics teams work around local cut-off times. Financial and technical systems timestamp events that may later need to be compared across countries.
The same misunderstanding sits behind many of these problems: assuming that the difference between two local clocks is permanent.
Often it is stable for long stretches of the year. That makes the assumption feel safe. Seasonal clock changes expose the weakness only occasionally, which is why the mistake keeps returning.
The practical response is not to memorize more offsets. There are too many exceptions, and the rules can change.
It is more reliable to treat local time as date-sensitive information. For an international meeting that matters, check the actual local times for that specific date, include the relevant time zone in the invitation and avoid assuming that last month’s conversion still applies.
London and Italy show how coordinated clock changes can preserve a stable relationship between two places. Arizona shows the opposite situation, where one location keeps its clock unchanged while the rest of the relationship moves around it.
That is why an international meeting can change during the year even when nobody touches the invitation. The meeting is fixed. The clocks around it are not.
