Why daylight saving exists
Daylight saving time (DST) shifts civil clocks forward, usually by one hour, for part of the year, so that evenings have more daylight. Roughly a third of the world’s time zones observe it: most of North America and Europe do; most of Asia and Africa do not; the southern hemisphere runs it in its summer, which is the opposite calendar half from the north.
Because it is set by governments, it is also unstable: start and end dates change, regions opt in and out, and some zones (Morocco, for example) adjust around Ramadan rather than the solstices. Any code that “knows” DST rules hardcoded is eventually wrong; the rules must be looked up, which is what the IANA time-zone database in your browser exists for.
The two weird hours
Every clock change creates one strange hour on each side:
- Spring forward: times that never existed. When clocks jump from 02:00 to 03:00, the wall times 02:00:00–02:59:59 simply do not occur that day. A booking “at 02:30” that night refers to nothing. Tools must detect this and either reject it or state the nearest real instant they used.
- Fall back: times that happen twice. When clocks fall from 02:00 to 01:00, every wall time in 01:00:00–01:59:59 occurs twice: once at UTC−04:00 (EDT) and again an hour later at UTC−05:00 (EST). “02:30?”-style arithmetic is ambiguous unless the offset or the intended occurrence is stated.
The Time Zone Converter and Date to Unix Timestamp both detect these cases and label exactly which interpretation was used.
Dates and times of the changes
There is no global schedule. The US changes on the second Sunday in March and the first Sunday in November (at 02:00 local); the EU on the last Sundays of March and October (at 01:00 UTC); the southern hemisphere on opposite-season dates; and some equatorial or high-latitude places never change at all. Because the US and EU transition on different dates, cross-Atlantic time differences are not constant through the year, a fact worth checking with the Time Difference Calculator before scheduling anything recurring.
Practical rules that avoid DST bugs
- Store instants (timestamps or ISO strings with offsets), never naked local times.
- Convert with IANA zone identifiers, resolved for the date in question.
- Never assume an offset is constant across a year, or across a single meeting that spans a change.
- For recurring meetings, re-derive each occurrence: the wall time can be stable only in one participant’s zone.
- When a specific year matters (next year’s schedule), check the actual rules: the DST Checker reports every transition of a zone and year from your browser’s own database.
What a clock change looks like in data
For America/New_York in a typical year the checker reports two transitions: clocks
jump forward from 02:00 to 03:00 in March (UTC−05:00 → UTC−04:00) and fall back from 02:00 to 01:00
in November (UTC−04:00 → UTC−05:00). Zones with no DST (such as Asia/Kolkata,
Asia/Tokyo, or Africa/Cairo) report a single offset all year. If a
zone reports none for two years straight, it may have legislated DST away: the tool’s two-year scan
window makes that visible rather than assuming rules continue forever.