A recurring meeting works perfectly all winter, then one week half the participants arrive an hour late. Nothing changed in the calendar. What changed was that one country moved its clocks and the other did not, on a date neither party thought about.
Offsets are properties of moments, not places
The common mental model — that a place has an offset from UTC — is wrong in a way that causes real bugs. New York is not UTC-5. New York is UTC-5 in winter and UTC-4 in summer. The offset is a property of a specific moment in a specific place, which is why converting a time requires knowing the date.
This is why abbreviations like EST are treacherous. EST specifically means Eastern Standard Time, the winter offset. A meeting described as 3pm EST in July is technically an hour off from what everyone assumes, because July is EDT. Worse, some abbreviations are genuinely ambiguous: CST means Central Standard Time in North America, China Standard Time in Asia, and Cuba Standard Time in the Caribbean.
Daylight saving is not globally coordinated
The transition dates differ by region, and this is the single most common source of scheduling errors. The United States and Europe shift on different weekends, producing a window of two to three weeks each spring and autumn when the usual difference between London and New York is one hour out.
Below the equator, seasons are inverted, so Australia and New Zealand shift in the opposite direction to the northern hemisphere. And many places do not observe daylight saving at all — including India, China, Japan, and most of Africa. Within countries it can vary: most of Australia shifts, but Queensland does not.
Not every offset is a whole hour
India runs at UTC+5:30. Nepal at UTC+5:45. Newfoundland at UTC-3:30, and parts of Australia at UTC+8:45. Code and mental arithmetic that assume whole-hour offsets break on all of these, and they are not obscure edge cases — India alone accounts for a substantial share of the world's meetings.
The IANA database is the source of truth
Because all of this changes by political decision, the world relies on a maintained dataset: the IANA time zone database, which records every zone's historical and current rules under identifiers like America/New_York and Asia/Kolkata. It is updated several times a year as governments announce changes.
Those identifiers are what you should store and communicate, not abbreviations or raw offsets. Asia/Kolkata is unambiguous; IST could be India, Ireland, or Israel.
Practical rules for scheduling
- State the zone as a city or IANA identifier, not an abbreviation: "3pm London time" beats "3pm GMT".
- For recurring meetings, re-verify after each daylight saving transition rather than assuming the difference held.
- When storing timestamps in software, store UTC plus the intended zone identifier, not a local time and an offset.
- For anything critical across zones, include the UTC time alongside local times so there is a single unambiguous reference.