Choose the time in one named zone, the one the meeting belongs to, such as Europe/Madrid, and check the date against that zone's daylight saving rules rather than against today's offset. Then write the invitation with the weekday, the date, the time and the city, plus the UTC time as a cross-check. Most wrong-hour meetings come from converting with an offset that was true when the person did the sum and is not true on the day.
Why does a conversion that was right last month come out an hour off?
Because the gap between two cities is not constant. The offset of each city moves on its own schedule, and the schedules do not line up. If you worked out "New York is six hours behind Madrid" in the summer and applied it to a November meeting, you were using a number with an expiry date. The difference between a timezone and an offset explains it: the zone is the rule, the offset is one reading of it.
For a meeting that has not happened yet, the zone name is what you convert from. The offset is something you look up for that specific date.
When do the US and Europe disagree about the time?
Both switch twice a year, on different dates. In the United States, clocks go forward on the second Sunday in March and back on the first Sunday in November, at 02:00 local time. In the European Union, they go forward on the last Sunday in March and back on the last Sunday in October, both at 01:00 UTC. The EU has debated ending the switch since 2018 and, as of the European Parliament's debate in October 2025, has not decided; the proposal still needs the Council and Parliament to agree. Check before assuming the rule holds for a date years away.
For 2026 that produces two stretches where the usual gap is wrong:
- 8 to 29 March: New York has already moved to
-04:00, Madrid is still on+01:00. The gap is five hours, not six. - 25 October to 1 November: Madrid is back on
+01:00, New York is still on-04:00. Five hours again.
That is about four weeks out of fifty-two in which a "six hours" rule of thumb is wrong, and the weeks fall exactly where people schedule a lot: the end of a quarter, the start of a sprint. The dates move every year because the rules are "the Nth Sunday", so do not copy these into a template. Look them up for the year of the meeting.
Other places add their own timetables. Southern-hemisphere zones that observe daylight saving, such as New Zealand, move in the opposite season. Many places do not move at all: America/Argentina/Buenos_Aires stays on -03:00 and Asia/Kolkata on +05:30. So the gap between Madrid and Buenos Aires is four hours in winter and five in summer, because only one side moves.
Which zone should the meeting be pinned to?
The one where the people or the place that define the meeting are. A weekly team call belongs to the team's home zone. A webinar belongs to the host's. A shop opening or a flight belongs to the place it happens in. Everyone else is a conversion of it.
Pinning matters most for recurring meetings. If "every Monday at 09:00 Madrid" is the rule, colleagues in New York will see it move by an hour in their own calendar during the stretches above, and nothing is broken: Madrid's clock stayed put and theirs moved. If instead you pin it to New York, Madrid sees the shift. Decide which side absorbs the change and say so in the invitation, otherwise the people it moves for will assume a mistake.
For a one-off meeting, do the conversion once, for the actual date, not for today.
How do you write an invitation that cannot be misread?
Give the reader enough that a mistake in any one part is visible against the others:
- The weekday and the full date, with the month spelled out. "4/11" is April in one country and November in another.
- The time in 24-hour form, with the city or IANA zone name beside it:
15:00 Madrid. - The same instant in UTC:
14:00 UTC. - Optionally one or two of the attendees' local times, when you know them.
For example: Wednesday 4 November 2026, 15:00 Madrid (14:00 UTC; 09:00 New York). Three numbers that agree are hard to misread, and when they disagree somebody will notice.
Do not use three-letter abbreviations as the only label. CST is Central Standard Time in the US, China Standard Time and Cuba Standard Time, and IST is claimed by India, Ireland and Israel. A city name is unambiguous in a way an abbreviation is not. Do not write "your time" without saying whose.
What about meetings that cross midnight?
The date changes along with the time. The same meeting, 14:00 UTC on Wednesday 4 November 2026, is 03:00 on Thursday in Auckland, where it is on +13:00. A person in that zone who reads "Wednesday" will turn up a day early or conclude it is not for them. When an attendee is more than about ten hours from the organiser, include their local weekday, not only their local time. Or choose a slot that falls on the same date for everyone, if one exists.
How can you check the conversion in your browser?
Use the date-to-timestamp side of the Unix timestamp converter. Type the meeting date and time, set "Interpret it as" to UTC, and the result shows the same instant in your own local time and in UTC. If your device is in a zone with a different rule to the meeting's, you get an independent check against what the calendar says. Everything is calculated on your device, and nothing is uploaded.
The converter's limits matter here. There is no zone picker: it only knows UTC and your device's zone. You cannot ask it what time a meeting is in Madrid unless you work backwards from UTC yourself, and you cannot ask it what Madrid's offset will be on a given date. When the date you type falls on a clock-change day, it does not warn you that a local time was skipped or repeated; the browser silently chooses a reading. Typing the time as UTC avoids that ambiguity, which is a reason to prefer UTC for the input. For an instant, no zone is needed at all.
What should you do when the meeting is near a clock change?
Re-send it. If you created the event before the clocks moved, a modern calendar keeps it at the wall-clock time in the zone it was created in, so it is usually right. If you sent it as plain text, or someone copied it into a spreadsheet as a UTC time, it is not. A message the day before with the three numbers again costs less than one person missing the start. When someone says the time is wrong, ask which zone they converted from before arguing about it.
To check a time you worked out, enter it as UTC in the Unix timestamp converter and read the local result for your own device. It only knows your zone and UTC, so it does not replace looking up the other city's rules for that date.
If you want the reasoning behind pinning a meeting to a named zone, a timezone is not an offset goes through what you lose by storing only the number.
Frequently asked questions
What is the best way to schedule a meeting across time zones?
Pick the time in one named zone, normally the one the meeting belongs to, such as Europe/Madrid. Check that date against the daylight saving rules of every attendee. Write the invitation with the weekday, the full date, the time and city, and the same time in UTC, so each part can be checked against the others.
Why is a meeting an hour off for some people only some weeks of the year?
Different places change their clocks on different dates. In 2026 the US moved on 8 March and the EU on 29 March, so for three weeks the gap between New York and Madrid was five hours instead of six. The same happens in autumn, between the EU change on 25 October and the US one on 1 November.
Should I send a meeting time in UTC or in local time?
Send both. The local time in a named city tells people what the organiser means, and the UTC time lets anyone check the conversion. UTC alone is correct but makes every attendee do a sum; local time alone leaves out the information needed to check it.
Does a recurring meeting move when daylight saving changes?
It stays fixed in the zone it was created in and moves in everyone else's calendar when only one side changes its clocks. A weekly 09:00 Madrid meeting stays 09:00 in Madrid but shifts an hour for New York in the weeks when only one of them has changed. Say which side keeps the fixed time.
Can I trust EST, CST or IST in an invitation?
Not on their own. CST can mean US Central, China or Cuba Standard Time, and IST can mean India, Ireland or Israel. Use a city name or an IANA name such as America/Chicago, and treat the abbreviation as optional decoration for people who like it.
Last updated October 30, 2026
