Time zone changes and out-of-date devices

The rules live on your device, not on this site

We do not ship a copy of the time zone rules. Every tool here that resolves a zone reads them out of your browser, through the standard international formatting interfaces browsers expose. Your browser carries a copy of the IANA Time Zone Database — the same dataset operating systems and browsers themselves work from.

That is deliberate: there is no copy of the rules on this site to go stale. A table of transitions bundled here would be identical for every visitor and would start ageing the day it shipped.

One thing here is vendored, and it is worth naming rather than glossing over. The list of zone and place names — which city labels which zone, and which country a zone belongs to — is a table generated here from pinned copies of IANA, GeoNames and CLDR data, because no browser interface supplies that join at all. That table can go out of date: a zone added to the database after the version we pinned will not appear in the picker until it is regenerated.Sources records the exact versions.

The cost is what this page exists to state. The freshness question does not disappear — it moves onto your device. If your device’s copy of the rules is old, every answer this site gives for an affected zone inherits that, quietly.

How a rule change reaches you

Time zone rules are law, and governments change them — sometimes years ahead, often with a few weeks’ notice. The IANA database is revised several times a year to keep up, each revision a small numbered release: 2026a, 2026b, 2026c and so on.

None of those reaches you directly. Operating system and browser vendors pick them up, and they arrive inside an ordinary update; a device that is not updated keeps using the rules it last received, indefinitely. Phones and desktops that install updates are usually fine. The ones that drift are out of support, managed by an employer that batches updates, or deliberately held back.

Four recent changes

The ones most likely to make two devices disagree right now, each sourced to the release that introduced it. Where the release notes state the change in a sentence, that sentence is quoted here rather than paraphrased — paraphrasing a date out of a release note is how a wrong date gets published, and it is a mistake this page’s own earliest notes contained.

• Alberta, Canada — release 2026c. “Alberta’s 2026-03-08 spring forward was its last foreseeable clock change, as it moved to permanent -06 thereafter.” It sprang forward that March and never went back, so -06 — six hours behind UTC — now applies all year.
• British Columbia, Canada — release 2026b. “British Columbia’s 2026-03-08 spring forward was its last foreseeable clock change, as it moved to permanent -07 thereafter.” The same shape, one hour further west.
• Morocco — release 2026c: permanent +00 from 2026-09-20 at 02:00. Morocco previously kept +01 with a temporary drop around Ramadan, on a rule driven by the lunar calendar rather than a fixed date.
• Moldova — release 2026a. Moldova has observed EU transition times since 2022, so Europe/Chisinau springs forward at 03:00 local rather than 02:00. In 2026 that is 2026-03-29T01:00:00Z — the same instant as Athens, Berlin and London — local clocks moving 03:00 to 04:00; the autumn change is2026-10-25T01:00:00Z, local 04:00 back to 03:00. Only the moment moved.

The British Columbia entry has a wrinkle worth knowing

Release 2026b records that although the change to permanent -07 legally took place on 2026-03-09, the release temporarily models it as occurring on 2026-11-01 at 02:00 instead, to work around a limitation in CLDR 48.1, dated 2026-01-08. CLDR is the locale data supplying zone names and labels — a separate dataset from the rules, shipped by a different project on a different schedule.

We quote that rather than explaining it, deliberately. How the modelling actually behaves in the shipped data is a detail this project has already recorded itself getting wrong once, and the reader-facing point does not depend on it: when two sources disagree about when a change happened, a modelling decision taken to work around a downstream dataset is often the reason, and it is not evidence that either source is wrong about the law.

When an out-of-date device is actually wrong

This is the part usually got wrong, including in the notes this page was first drafted from. The instinct is to key a warning to the date of the legal change — the law changed on such a date, therefore anything after it is suspect on an old device. That is wrong in the expensive direction: it raises alarms on dates where the old device is provably right.

Divergence between an out-of-date device and a current one begins at the out-of-date device’s next transition, not at the date of the legal change.

Alberta makes it concrete. Take a device that still believes Alberta observes daylight saving:

• 2026-03-08 through 2026-10-31: the two devices agree exactly. The stale one has Alberta on -06 because it sprang forward in March. The current one has Alberta on-06 because that is now the permanent offset. Same answer, different reasons.
• From 2026-11-01 they diverge. The stale device applies a fall-back the current rules no longer contain, and puts Alberta an hour behind where it really is.

A warning keyed to the date of the law would have fired across all 237 of those days — close to eight months on which the out-of-date device was giving exactly the right answer. One keyed to the device’s own next transition fires on the affected dates and no others.

Why an updated browser calls Vancouver “MST”

Abbreviations get reassigned after changes like these. America/Vancouver is now labelled MST and America/Edmonton is labelled CST, so an up-to-date browser will render a Vancouver clock as MST — Mountain Standard Time — for a city on the Pacific coast.

Which abbreviation you actually see depends on which build of the database your browser shipped: the current development version of the database and the 2026b and 2026crelease archives differ on this point, so two updated browsers can legitimately disagree about the label while agreeing exactly about the time.

That looks like a bug and is not one. The label follows the offset, not the geography: Vancouver’s permanent -07 is the offset Mountain Standard Time uses, and Edmonton’s permanent -06 is Central Standard Time’s. Nothing about the time itself is wrong. We render these labels from your browser rather than hard-coding them, which is why they change without anyone here editing anything.

The United States has not changed its clocks

This is regularly reported as settled when it is not. Precisely: the House of Representatives passed H.R.139 by 308 votes to 117 on 2026-07-14 (Roll Call 238). It was received in the Senate, read twice and referred to the Senate commerce committee on 2026-07-15.

It is not law.

Passing one chamber and being referred to a committee in the other clears one of several steps. Until a bill clears the rest and is signed, United States clocks change on the existing schedule and the database carries the existing rules.

What no browser can tell you, however fresh it is

Freshness is not the only limit. Release 2022b moved the pre-1970 history of about 21 zones into a supplementary file that shipping browsers do not carry, so for those zones a browser has no accurate history before 1970 at all. Europe/Amsterdam,Atlantic/Reykjavik, Europe/Oslo, Europe/Stockholm,Europe/Copenhagen, Asia/Kuala_Lumpur, Pacific/Chuuk andPacific/Pohnpei are among them.

Measured: Amsterdam at the year 1900 reports an offset of zero — Brussels’ offset — rather than the database’s +00:19:32. Updating the browser does not fix it, because the history is not missing from your copy, it is absent from the file browsers ship. Nothing flags it, and the answer does not look wrong. That is one reason the zone-aware tools here floor at 1970.

What to do about it

• Install operating system and browser updates. That is the whole mechanism by which new rules reach you; there is no separate time zone update to fetch.
• For anything that matters, check an official source. A flight, a legal deadline, a contract — verify against the country’s own announcement rather than any converter, ours included.
• Allow for lag. A change announced this month may take weeks to reach the database, and weeks more to reach your device.

How this site handles it

There is no permanent “results may be wrong” banner here and there will not be one. A warning that is always showing is not information, it is decoration — and it teaches people to ignore it on the one occasion it means something.

A note is only worth showing when a check can establish two things at once: that the device’s data is behind, and that the answer currently on screen is affected by it. The Alberta example above is the whole argument — a note keyed to the first condition alone would have shown on every date a stale device could be asked about, including the 237 consecutive days on which it agreed with a current one.

Today no tool here detects staleness at all. Thetime zone converter says so plainly in its own limitations, and this page is the longer version of that sentence. When a check ships, it will appear beside the affected answer and nowhere else.

How the calculations are tested is on accuracy; where the data comes from is on sources.

Sources

• IANA Time Zone Database — the database and its releases.
• tzdb release notes (NEWS) — the source of every quotation above.
• Clerk of the House — Roll Call 238 — the 308 to 117 vote on H.R.139.