Daylight saving time guide for meetings and travel

The rule that prevents most mistakes

Treat the calendar date as part of the time zone. A short label such as EST, PST, CET, BST, or IST is a useful hint for readers, but it is not enough information for exact scheduling. The safer source of truth is a city-based zone such as America/New_York, America/Los_Angeles, Europe/London, Europe/Paris, or Asia/Kolkata plus the event date.

For a one-off event, convert the exact date and time with the Time Zone Converter. For a two-location comparison, use the Time Difference Calculator. For recurring team calls, compare at least one date before and one date after the next known clock-change period.

Common daylight-saving traps

• Assuming today's UTC offset will be correct for a future meeting.
• Writing only a short abbreviation when the audience spans multiple countries.
• Scheduling a recurring meeting across regions that change clocks on different weeks.
• Using a fixed offset for a city that changes between standard time and daylight time.
• Forgetting that locations such as India, Singapore, China, Japan, Arizona, and Hawaii may stay fixed while another meeting participant changes clocks.

The mistake is rarely that someone forgot arithmetic. It is usually that the arithmetic was correct for the wrong date or the wrong label. That is why TheWorldTimeMap route pages link back to data notes, region guides, and date-aware tools rather than presenting a single permanent offset as the final answer.

How to publish a time safely

When you publish a time for a meeting, livestream, interview, or customer event, include the weekday, date, local time, and city-based zone. For example, write the local event time for each major audience rather than asking readers to infer it from a short code. If the event repeats, add a reminder to re-check the slot around seasonal clock changes.

A good publishing checklist is simple: convert the event on the exact date, copy the local time for each audience, include the city or IANA zone next to every time, and test one future occurrence if the event repeats. If the schedule is for support coverage or incident response, add the UTC time as a neutral backup, but do not remove the local city labels. People usually act on local time, while systems and runbooks often need UTC.

Regional examples to check carefully

US, UK, European, Australian, Canadian, and Middle East planning can all behave differently because local rules and changeover dates are not universal. Use the region guides when you need context before converting a specific event date.

• US time zones for Eastern, Central, Mountain, Pacific, Alaska, Hawaii, and Arizona-style exceptions.
• UK time zones for GMT, BST, and London local time.
• Europe time zones for CET, CEST, UK, and Eastern Europe planning.
• Canada time zones for Atlantic, Newfoundland, Eastern, Central, Mountain, and Pacific differences.
• Australia time zones for state differences, half-hour offsets, and Sydney/Brisbane daylight-saving differences.

Data and review notes

TheWorldTimeMap uses browser-supported IANA time zones where possible. Governments can change local clock rules, and a visitor's device or browser may not receive time zone database updates at the same time as another system. Review Time Zone Data And Accuracy for how time data is handled, Editorial Policy for how guides are reviewed, or Feedback to report a correction.

For legal, medical, aviation, transport, finance, or safety-critical work, confirm final times with the responsible authority. This guide is for planning clarity and user education, not legal timekeeping.