DST transition finder

How to use

1. Choose a time zone. Filter the list by typing part of a city or region name; zone names look like Europe/Berlin. The buttons under the tool pick some instructive cases.
2. Type a four-digit year from 1900 to 2100.
3. Read the list. Each row gives the transition instant in UTC, the offset before and after, the size of the jump, and the range of local clock readings that never happens (clocks forward) or happens twice (clocks back). The first line says what the offset is at the start of the year.
4. If the zone has no change in that year, the page says so rather than showing an empty table.

To see what a particular clock reading in one of those ranges becomes in another zone, copy it into the time zone converter.

Worked examples

Each result below is recomputed by an automated test from the engine, and each transition printed here is also compared with Python's zoneinfo and Go's time package in the tests. Times in the first part of each line are UTC.

The northern hemisphere: New York, Berlin, London

All three change in March and October or November, but not on the same days, and London skips 01:00 to 01:59:59 while Berlin skips 02:00 to 02:59:59: both change at 01:00 UTC (the first column). The clock readings differ because the offsets before and after differ.

The southern hemisphere runs the other way

Sydney's clocks go back in April and forward in October, so the first row of the year is the "fall back" one.

A change that is not an hour

Lord Howe Island moves by 30 minutes, between +10:30 and +11:00.

A change at midnight

Cairo's clocks go forward at midnight, so the whole first hour of 24 April 2026 never happens, and when they go back, 23:00 to 23:59:59 on 29 October happens twice. A date-only value such as "2026-04-24" is still a valid date, but "2026-04-24 00:30" in Cairo is not a valid time.

No changes

History: a day that was removed, and a skipped midnight

In the data, Samoa's offset goes from -10:00 to +14:00, a jump of 24 hours, so every clock reading on 30 December 2011 never happened there.

For 2018 the data has São Paulo's clocks going forward at midnight, so 00:00 to 00:59:59 on 4 November never happened there. The page makes no claim about other years.

A zone whose pattern is inverted

For 2025 the data for Africa/Casablanca has the offset going down from +01:00 to +00:00 on 23 February and back up on 6 April. Compared with the other examples, clocks go back at the start of the period and forward at its end. For dates after 2026-09-20 the 2026c release records a permanent +00 for Morocco, which a browser with older data will not show (see the limits below).

What goes wrong

"DST" starts on the same date everywhere in the country

Not even within one country: the examples show Sydney and Lord Howe Island, both in Australia, changing at different instants and by different amounts, and the US and the EU change on different dates.

"Clocks always change at 02:00"

London changes at 01:00 local time, Cairo at midnight, São Paulo at midnight, and the readings that are skipped or repeated differ accordingly. Code that assumes "the ambiguous hour is 01:00 to 02:00" is wrong for most of these.

"The two changes in a year are an hour each, six months apart"

In 2026 New York is on daylight time from 8 March to 1 November, just under eight months, not six. Lord Howe moves by 30 minutes, and Samoa once moved by a day. A calculation that adds 1 hour per transition is wrong in those cases; use the offsets before and after each row.

Reading a future transition as certain

See the FAQ: Morocco, Alberta and Manitoba all changed their rules in 2026. A transition list for a future year reflects the rules your browser knows.

Treating the zone list as complete history

The IANA theory document says the database's zones are defined so that the clocks in each one agree from 1970 on, and notes the wide variety of local practices before then. The finder allows years from 1900 to 2100 but cannot say how reliable the data for an early year is.

Limits & gotchas

• Your browser's data, not an official list. The transitions are derived from the browser's built-in time zone data, which is a copy of the IANA database made at some release. The finder cannot tell which release. We saw a concrete difference while testing: a Node version with 2024b data and the 2026c data on the build machine disagree about Africa/Casablanca after 2026-09-20, and about a 1978 Asia/Tehran change.
• Only the total UTC offset is observed. A zone that changes both its standard offset and its DST amount so that the total stays the same would not appear, and the finder does not label a row as "DST" or "standard time".
• Sampling every six hours. Two changes that cancel out inside one six-hour window would be missed. None is known in the data we compared (see the next point).
• Checked against Python and Go. The tests compare the transitions of 41 zones with those produced by Python's zoneinfo and Go's time package, using the 2026c data on the build machine. That is a check of the engine, not of your browser's data.
• Years. 1900 to 2100, as UTC calendar years.
• Display names such as "Eastern Standard Time" come from the browser (English) and are informational.

FAQ

Sources

• IANA: Theory and pragmatics of the tz code and data Used for: The database records the history and the predicted future of civil time scales; names have the form Area/Location (for example Asia/Calcutta was renamed Asia/Kolkata, with the old name kept as a link); the abbreviation list shows that one abbreviation can mean different things (IST appears for India, for Irish time and for Israel).
• IANA: News for the tz database Used for: Recent rule changes made on short notice: release 2026c (2026-07-08) lists Alberta moving to permanent -06 and Morocco to permanent +00 from 2026-09-20; release 2026e (2026-09-29) lists Manitoba moving to permanent -05 on 2026-10-31.
• MDN Web Docs: Intl.supportedValuesOf() Used for: "timeZone" is a valid key and the call returns a sorted array of unique values supported by the implementation.
• Ecma International / TC39: ECMAScript Language Specification: Time Values and Time Range; Date.parse; time zone offset helper operations Used for: A time value is milliseconds since 1970-01-01T00:00:00Z with every day exactly 86,400,000 ms (leap seconds are ignored); the range is +-8.64e15 ms (+-100,000,000 days); for a local time that is skipped or repeated, the offset in use before the transition is applied; a skipped local time yields no instant in the time-zone-to-epoch operation.
• Python Software Foundation: zoneinfo: IANA time zone support Used for: ZoneInfo reads the IANA database and honours fold: the offset from before the transition is used when fold=0 and the offset after when fold=1; datetime + timedelta(days=1) is wall-clock arithmetic.
• The Go Authors: Go package time: Date Used for: Time.UnixNano is undefined for dates before the year 1678 or after 2262 (it must fit an int64). time.Date: in a transition that skips or repeats times (the doc's example is the US, 2011), "Date returns a time that is correct in one of the two zones involved in the transition, but it does not guarantee which."

Every document above was opened and read on 2026-10-03. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.

Related tools

• Time zone converter

  Convert a local time between IANA zones and see what happens when the time does not exist or happens twice.

• Date difference and add/subtract

  Calendar and elapsed-time arithmetic that is honest about DST, with month-end clamping explained.

• Unix epoch converter

  Seconds, milliseconds, microseconds or nanoseconds to a date and back, with the unit guess explained and exact BigInt arithmetic.

• ISO 8601 duration calculator

  Parse PnYnMnDTnHnMnS, see why months and years are not fixed lengths, and apply a duration to a date.