Time zone changes in 2026: what changed, and how to check your calendars and systems

The short answer

Between March and October 2026, four Canadian jurisdictions stopped changing their clocks, Morocco returned to UTC+0 all year, and Cuba cancelled its November fall-back. Each change reached software as a new release of the IANA time zone database (tzdata): 2026b, 2026c, 2026d, 2026e and 2026f. A phone, laptop or server whose tzdata is older than the release for a given place shows that place's time one hour wrong, with no error.

Three things to do:

1. Confirm your devices, runtimes and databases have tzdata 2026f or later. The test is further down.
2. Re-check recurring meetings that include anyone in British Columbia, Alberta, the Northwest Territories, Manitoba, northwestern Ontario, Morocco or Cuba.
3. Recompute any future timestamps your systems stored as UTC for those places before the update.

All offsets below were computed from tzdata 2026e as bundled with Node.js 22.23.4, except Cuba, which we computed from the 2026f source compiled with zic. The dates and release numbers come from the IANA tz NEWS file and the government sources linked in each row.

What changed, place by place

UTC offsets on 15 January of each year, so the before/after is visible in winter, when the changes bite:

Sources by row:

• British Columbia: the province announced on 2 March 2026 that the 8 March spring-forward would be its last clock change (BC Gov News).
• Alberta: the new Official Time Act came into force on 18 June 2026 by Order in Council 204/2026 (Alberta King's Printer). The East Kootenay regional district and the Town of Golden in BC have historically kept Alberta's time, and in 2026 voted to stay with it on UTC−6, as the tz maintainers record in the northamerica data file.
• Northwest Territories: a regulation registered on 18 August came into force on 21 August 2026 (NWT Justice).
• Manitoba: the government announced permanent UTC−5 on 17 September 2026 (Manitoba news release), in force on 31 October. Ontario followed for the area west of 90°W with Regulation 333/26, in force 1 November 2026.
• Morocco: the change back to GMT on 20 September 2026 was announced in June and ended the UTC+1 system in place since 2018 (The New Arab; tz release 2026c).
• Cuba: the authorities announced on 24 October 2026 that clocks would stay on daylight time until 7 November 2027 (Cuba government portal; tz release 2026f). That was eight days' notice.

Saskatchewan, Yukon, Ontario outside the northwest, Quebec and the Atlantic provinces did not change. Saskatchewan passed a new Time Act in 2026 that keeps its existing year-round UTC−6, according to the tz release notes for 2026f.

Paraguay, the 2024 precedent

Paraguay stopped changing its clocks after its spring-forward on 6 October 2024 and stayed on UTC−3. The tz database caught up in release 2025a on 15 January 2025, and the first timestamp where old and new data disagree was 22 March 2025, when the old rules would have moved Asunción back to UTC−4 (IANA tz 2025a). Vendors had about nine weeks; Microsoft published interim guidance for Windows before its update shipped. Cuba's 2026 change gave everyone eight days.

What the new offsets do to familiar time differences

These differences hold from 1 November 2026 until the U.S. springs forward on 14 March 2027, computed from tzdata:

• Vancouver is one hour ahead of Seattle and Los Angeles. A 09:00 call in Vancouver is 08:00 in Los Angeles this winter; last winter both cities read 09:00.
• Vancouver is two hours behind Toronto, not three. 09:00 Vancouver was 12:00 Toronto in January 2026 and is 11:00 Toronto in January 2027. London moves the same way: 17:00 last January, 16:00 this January.
• Calgary and Edmonton are one hour ahead of Denver, and now match Regina all year.
• Winnipeg reads the same time as Toronto, and is one hour ahead of Chicago.
• Casablanca reads the same time as London in winter and one hour behind it in summer. Until September 2026 Morocco was usually one hour ahead of London in winter. A 09:00 Casablanca meeting is 10:00 in London in July 2027; in July 2026 it was 09:00.
• Havana is one hour ahead of New York, with 2026f data. With 2026e or older, software shows the two cities at the same time.

From 14 March 2027 the U.S. and the eastern Canadian provinces move to summer time, and Vancouver matches Los Angeles again. The full 2027 calendar of these windows is in our post on the DST mismatch weeks of 2027.

Why stale tzdata fails silently

Software does not look up the time for a city online. It converts with a rule table stored on the device, in the runtime or in the database. An old table has no expiry date: a device on tzdata 2026e still believes Cuba fell back on 1 November and will spring forward again on 14 March 2027. It shows Havana at UTC−5 and raises no error.

Display names add a second problem. To work around limits in Unicode CLDR 48 and ICU 78, the libraries that browsers and Node.js use to name time zones, the tz maintainers record the Canadian changes as taking effect on 1 November 2026 at 02:00 rather than on the legal dates (tz NEWS, 2026b to 2026e). The offsets are right, but the labels vary by software. For 15 January 2027 in Vancouver, the tz database's own abbreviation is MST. Node.js 22.23.4 (ICU 78.3) labels the same moment "Pacific Daylight Time". The BC law calls it "Pacific Time".

Identify zones by IANA ID (America/Vancouver) and show numeric offsets (UTC−7). Do not parse or store abbreviations like PDT or MST.

Recurring meetings and calendar invites

Meetings stay put in the organiser's zone and move for everyone else. A weekly 09:00 meeting set in America/Vancouver still starts at 09:00 in Vancouver. For a colleague in Toronto it moved from 12:00 to 11:00 on 1 November and will move back to 12:00 on 14 March 2027.

Invites carry their own copy of the rules. An iCalendar file must include a VTIMEZONE component for every time zone it references (RFC 5545, section 3.6.5). An invite generated before a client had the new data carries the old rules, and calendar clients differ on whether they trust the embedded definition or their own database. After updating, open one future occurrence (for example, a Monday in January 2027) as seen by an attendee in each affected place. If it is off by an hour, re-send the series from an updated client so it carries fresh definitions.

Fixed offsets drift. A meeting saved in "GMT−08:00" or in a generic "Pacific Time (US & Canada)" setting does not follow British Columbia's new rule. People in Vancouver whose device is set to Los Angeles time see clocks one hour wrong this winter. On Windows, Microsoft shipped a British Columbia time zone update, so check that BC machines use it.

To check one occurrence, enter its date and time in the time zone converter, which takes a date as well as a time. It converts with your browser's own copy of the rules, so on a device whose tzdata predates the release for that place it shows the old offset. That also makes it a quick test of the device.

Stored timestamps in databases and apps

For past events nothing changes: the UTC instants are the same, and the new rules only affect times after the legal change dates.

For future events it depends on what you stored:

• Local time plus IANA zone ID (for example 2027-01-15 09:00, America/Winnipeg): correct, as long as you convert to UTC with updated tzdata when you use it.
• UTC computed in advance: wrong by one hour for every winter timestamp in an affected zone, if it was computed before the relevant release. A 09:00 Winnipeg appointment on 15 January 2027 stored as 15:00 UTC with pre-2026e data should be 14:00 UTC. Recompute these from the original local time.

Runtimes do not share one copy of the data:

• PostgreSQL ships its own copy of the tz database unless it was built with --with-system-tzdata (PostgreSQL docs). Upgrading the operating system does not update it.
• Java uses the tzdata bundled with the JDK; Oracle's TZUpdater patches it between releases.
• Python's zoneinfo reads the system database and falls back to the tzdata package from PyPI (Python docs).
• Browsers and Node.js use the copy bundled with their ICU library, which updates with the browser or Node release.

How to check which tzdata you have

The most reliable test checks behaviour rather than a version string, because it works anywhere JavaScript runs. Paste this into a browser console or node:

const off = (zone) =>
  new Intl.DateTimeFormat("en-US", { timeZone: zone, timeZoneName: "longOffset" })
    .formatToParts(new Date("2027-01-15T12:00:00Z"))
    .find((part) => part.type === "timeZoneName").value;
console.log(off("America/Winnipeg"), off("America/Havana"));

• GMT-05:00 GMT-04:00: tzdata 2026f or later. Up to date.
• GMT-05:00 GMT-05:00: 2026e. Canada is right, Cuba is not. This is what Node.js 22.23.4 prints.
• GMT-06:00 …: older than 2026e. Manitoba is wrong, and possibly British Columbia, Alberta and the Northwest Territories too.

Version strings, where available:

• Node.js: node -p process.versions.tz
• Debian and Ubuntu: dpkg -s tzdata | grep Version, or head -1 /usr/share/zoneinfo/tzdata.zi, which prints a line such as # version 2026e
• Python with the PyPI package: python3 -c "import importlib.metadata as m; print(m.version('tzdata'))". Letters map to numbers, so 2026f is 2026.6.
• Java: java -jar tzupdater.jar -V prints the JRE's tzdata version.
• PostgreSQL: there is no version query. Test the behaviour: SELECT timestamptz '2027-01-15 12:00+00' AT TIME ZONE 'America/Havana'; returns 08:00 with 2026f data and 07:00 with older data.

The DST tracker lists each country's current status, and the DST 2026 global overview has the full country-by-country picture. Local pages for Vancouver, Calgary, Toronto and Casablanca show the current offset in each city.

The U.S. Sunshine Protection Act

Nothing to update yet. The House passed H.R. 139 on 14 July 2026 by 308 votes to 117 (House roll call 238). It was referred to the Senate Commerce Committee, and as of 5 November 2026 the Senate has not voted. A bill not enacted when the 119th Congress ends on 3 January 2027 has to be reintroduced. Until a bill becomes law, the U.S. keeps its current schedule: the next changes are 14 March and 7 November 2027, both at 02:00 local time.

If it passes, it will reach devices the same way as the changes above: as a tzdata release, then operating system and runtime updates.

FAQ

Which places changed time zone rules in 2026?

British Columbia, Alberta, the Northwest Territories and Manitoba stopped changing their clocks and stayed on summer time all year, as did northwestern Ontario west of 90°W. Morocco returned to UTC+0 permanently on 20 September 2026. Cuba cancelled its 1 November 2026 fall-back and stays on UTC−4 until 7 November 2027.

Which tzdata version do I need?

Version 2026f or later, released on 27 October 2026. Version 2026e handles all the Canadian changes but not Cuba's.

Why does my phone show the wrong time for Havana?

Its time zone data is older than tzdata 2026f, so it still applies the old rule that Cuba fell back to UTC−5 on 1 November 2026. The fix comes with an operating system update. Until then, Havana is one hour ahead of what the device shows.

Sources

• IANA tz database: NEWS file, northamerica data file, release notes 2025a, 2026c and 2026f.
• BC Gov News: Adopting permanent daylight saving time.
• Alberta Official Time Act, chapter O-5.7.
• Northwest Territories Interpretation Act regulation.
• Government of Manitoba news release, 17 September 2026 and Ontario Regulation 333/26.
• Cuba government portal, 25 October 2026.
• The New Arab: Morocco's return to GMT.
• Congress.gov: H.R. 139 and House roll call 238.
• RFC 5545, iCalendar.
• PostgreSQL installation docs, Oracle TZUpdater, Python zoneinfo.
• Microsoft DST blog: British Columbia update and Paraguay interim guidance.