A meeting can be scheduled correctly on one person’s calendar and still be misunderstood by someone across the world. “Tuesday at 10” leaves out the detail that matters: whose 10 o’clock? A team-wide convention gives organizers and attendees the same reference point, while a careful invite makes the actual date and time easy to confirm. Agreeing on a few simple habits also helps when daylight-saving time starts or ends, or when a recurring meeting crosses a seasonal clock change. The aim is not to eliminate every calendar difference; it is to make assumptions visible and easy to check.
The useful bits
- Choose one default reference zone and name it with a city or region, not just an abbreviation.
- Check the date, time, and zone in the invite before sending, then confirm the displayed time for another region.
- Recheck recurring events around daylight-saving changes and clarify whether local time or a fixed reference time should stay constant.
Choose the convention before scheduling
Start by agreeing what the team’s default means. For a team anchored to an office or project location, use that location’s time zone as the reference for shared planning. For a fully distributed group without a natural home base, consider using one agreed reference zone for scheduling and naming it every time. The best choice is the one people can identify and apply consistently, not a zone chosen because it sounds universal.
Use a city or region name, such as “London time” or “Singapore time,” rather than relying on short forms such as “CST.” Abbreviations can refer to different places, and they do not always make seasonal clock changes clear. If the team uses a written convention, record it somewhere members can find and include the date it was agreed, so new members do not have to guess.
Decide what stays fixed
A key choice is whether an event follows a person’s local clock or a fixed reference time. For a one-off meeting, organizers can state the intended time in the agreed reference zone. For a recurring event, decide whether it should remain at the same local time for a particular group or at the same reference-zone time throughout the year. Those intentions can diverge when one region changes clocks and another does not.
For example, a weekly check-in intended to happen at 9 a.m. for a London-based team may shift for colleagues elsewhere when seasonal clocks change. If the priority is that a particular group keeps meeting at 9 a.m. local time, say so and review the corresponding times for other regions. If the priority is a fixed reference time, make that explicit too. Do not assume that “weekly at 9” communicates which rule applies.
Make the invite self-explanatory
When creating an event, check the calendar’s selected date, start time, end time, and time-zone setting before sending. Put the reference zone in the event title or description as well as relying on the calendar display. That gives recipients a readable cue if they view the invitation in a different calendar or forward its details.
Write the full date, including the month, and identify the zone by a recognizable place. Avoid a time-only note or an unexplained abbreviation. If the event has a video call or another joining method, check that the invitation presents the schedule and joining details clearly; do not assume that a correct meeting link means the time is correct.
Project review — [Tuesday, 14 April], [10:00–10:45] London time For colleagues in other regions, please check the local time shown in your calendar. This is a one-off meeting.
Check what recipients will see
Before sending, compare the event details with the team convention: Does the date match the intended day? Is the named reference zone correct? Does the end time allow for the intended duration? If the calendar offers a way to view another zone or recipient’s local time, use it as a cross-check, not as a substitute for stating the reference zone.
For a high-impact meeting, ask one attendee in another region to confirm the date and local time they see. If that is not practical, include a brief conversion for the regions that need it, taking care to label each place and date. Time conversion can cross midnight, so a recipient’s local date may differ from the reference date. The invitation should make that change clear rather than leaving attendees to infer it.
Treat daylight-saving dates as a review point
Daylight-saving rules vary by location and can change over time. Some regions adjust their clocks while others do not, and the change dates may differ. A recurring invitation that looks right now may therefore show a different local time for some attendees later in the year.
Before a seasonal clock change, review upcoming recurring events that include people in affected regions. Confirm whether the calendar’s displayed times still match the team’s stated intention. If the meeting is meant to stay at a particular local time, check that it does. If it is meant to stay at a fixed reference-zone time, tell attendees that other regions’ local times may shift. If the invite appears ambiguous or inconsistent, clarify it with the group and update the event rather than expecting recipients to work out the intended schedule.
Use a short send-and-confirm checklist
You can tell the convention is working when organizers consistently name the reference zone, attendees can identify the intended date and time without guessing, and seasonal changes prompt a deliberate review. If people keep asking which time zone an invite uses, treat that as a sign to improve the shared wording or revisit the convention—not as a failure by the people reading it.
- State the full date, start and end times, and a named reference zone.
- For recurring events, say whether local time or reference-zone time should remain fixed.
- Check the displayed local time and date for at least one other region when possible.
- Review affected recurring events around seasonal clock changes.
- If anything is unclear, send a correction that names the event and its intended time.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction
