Time Zones and DST for Developers
The handful of rules that prevent most time zone bugs, with the daylight saving edge cases explained.
Store UTC, display local
Store moments in time as UTC timestamps or ISO 8601 strings that end in Z, and convert to a time zone only when you show them to a person. This keeps comparisons and sorting simple and avoids ambiguity when servers, browsers and users are in different places.
Use IANA zone names, not offsets or abbreviations
A region name such as Europe/Paris or America/New_York identifies a place and includes its full history of rule changes. An offset like +01:00 only describes one moment, and an abbreviation like IST can mean India, Ireland or Israel. When you need to know what the local time will be next month, you need the zone name.
Daylight saving edge cases
When clocks spring forward, a whole hour of local time does not exist. On 8 March 2026 in New York, 02:30 never happens. When clocks fall back, an hour happens twice: 01:30 on 1 November 2026 occurs once in daylight time and once in standard time. Code that assumes every local time maps to exactly one instant will misbehave on those two days.
It also means days are not always 24 hours long. Adding 24 hours to a local date-time is not the same as adding one calendar day. Use a date library or Intl-based conversions for calendar arithmetic, and use plain timestamps for durations.
Recurring events and rule changes
For a recurring meeting at 09:00 local time, store the local time and the IANA zone, not a fixed UTC time, so it stays at 09:00 when daylight saving starts. Governments also change their rules, sometimes with little notice, and the IANA time zone database is updated several times a year. Keep your runtime, browser and operating system updated so the rules stay current.