How does daylight saving time work?
A statutory instruction to shift the civil clock, encoded in a database your phone carries, applied automatically — until two countries disagree about the date.
The short answer
A government defines a rule — “forward one hour on this Sunday” — and every device gets it from the IANA time zone database.
Your phone changes on its own because it looks up the rule for its current zone. Anything that stored a plain offset instead of a zone name does not change, which is where most daylight-saving bugs come from.
Step one: somebody legislates it
Daylight saving is a legal instrument, not a natural phenomenon. A national or regional government sets the rule, and the rules genuinely differ:
- United States: second Sunday in March to first Sunday in November, switching at 02:00 local time — so it rolls across the country over three hours.
- European Union: last Sunday in March to last Sunday in October, switching at 01:00 UTC — so the whole union changes at one instant.
- Australia: varies by state. Some observe it, some do not.
Rules change. Countries adopt, abandon and reschedule daylight saving fairly regularly, which is why this cannot be hard-coded.
Step two: it goes in the tz database
The IANA time zone database — the tz database, or zoneinfo — is the shared record of every zone's rules, including historical ones going back decades. It is maintained collaboratively and updated several times a year as governments make changes.
Zones are identified as Area/City: America/New_York, Europe/London,
Asia/Kolkata. The city is a stable label for a set of rules, not a claim
about geography.
Step three: your device applies it
Your phone knows it is in America/New_York. When it needs to display local
time, it takes the current instant, looks up the rules for that zone on that
date, and applies whichever offset was in force.
This is why the change happens without you doing anything, and why it happens correctly for dates in the past and the future.
Why some things change and others do not
The whole class of daylight-saving bugs comes down to what was stored.
| Stored as | Survives a clock change? |
|---|---|
| An instant (UTC timestamp) | Yes — UTC has no transitions |
| A zone name plus a local time | Yes — the rule is re-applied |
| A fixed offset, e.g. "UTC−5" | No — it is frozen at one season |
| Text, e.g. "3pm EST" | No — nothing converts it |
A calendar invite created properly carries a zone and converts itself. The same time pasted into the invite's description does not, which is why the body and the event so often disagree after a transition.
Where it still goes wrong
Two regions on different dates. The US and EU switch three weeks apart in spring. Nothing is buggy; the gap really is an hour smaller for those weeks. See why they differ.
Local-time arithmetic. Adding 24 hours to a local timestamp is wrong on transition days — the real elapsed time is 23 or 25 hours.
Stale data. A device or server with an old tz database applies the previous rule. When a country changes its rules at short notice, unpatched systems are simply wrong until they update.
Related: Daylight saving time explained · The tz database
Timezone: World Clock Widget
A world clock, converter and live day/night map for iPhone — 325 cities, offline, no account.
Figures on this page are computed from the IANA time zone database. Last generated 2026-08-18.