Split View: tzdata 2026c — 캐나다는 시계 돌리기를 멈추고, 모로코는 GMT로 돌아간다

tzdata 2026c — Canada Stops Turning the Clocks, Morocco Returns to GMT

• Introduction — July 8, the Infrastructure Nobody Reads the Release Notes For
• This Year's Three Releases, at a Glance
• Western Canada Stops Turning the Clocks
• Vancouver's New Abbreviation Is MST — the Trouble with Picking Abbreviations
• Why tzdb Deliberately Carries a Wrong Transition Date — the CLDR 48.1 Constraint
• Morocco Returns to +00 After Eight Years — and the Predictions Through 2087 Get Erased
• The Quiet Default Changes in 2026a
• When Does Your Stack Get 2026c — Two Deadlines
• Closing
• References

Introduction — July 8, the Infrastructure Nobody Reads the Release Notes For

On July 8, 2026, the IANA Time Zone Database shipped tzdata 2026c, its third release of the year. This database is a bundle of text files holding the UTC offset, transition rules, and historical change record for every time zone on Earth, and it lives somewhere in your stack no matter what that stack is — the /usr/share/zoneinfo that glibc reads, the JDK's own bundled copy, the copy embedded in the Go standard library, and, via ICU, the browser, Node, and Android.

The reason this data gets updated is always the same: some government changed a law about time. This year's input was unusually heavy — two Canadian provinces (and soon, probably, a third territory) abolished seasonal clock changes, and Morocco decided to return to GMT after eight years. Along the way, something rare happened: tzdb, constrained by CLDR, deliberately carried a transition date that differs from the actual legal effective date.

This post traces what the year's three releases (2026a/2026b/2026c) actually changed, based on primary sources — the NEWS file and the zone data, and lays out what to check before the two fall deadlines. The general theory of time zones and timestamps was already covered in Timestamps and Time Zones, Done Right, so here we only look at what actually changed in 2026.

This Year's Three Releases, at a Glance

tzdata isn't released on a schedule — it ships "whenever it's needed." Over the last three years (2023-2025) there were 4, 2, and 3 releases respectively, and this year is already on its third by July. And, as the NEWS file signals, the Northwest Territories situation means another release is likely needed soon.

Western Canada Stops Turning the Clocks

British Columbia (BC) went first. Per the BC government announcement (2026AG0013), the spring-forward transition on March 8, 2026 was the last clock change, and BC stays at -07 year-round after that. The legal wording is amusing — per Paul Eggert's summary as quoted in the tzdb comments, the new standard time, Pacific Time, "starts the following day (March 9, 00:00), 21 hours after the usual PST→PDT transition at 02:00 on March 8." In other words, the clock changes once, but the name change happens twice, 21 hours apart.

Alberta followed. The path there is interesting in a bureaucratic way — Section 3 of Bill 31 (the Red Tape Reduction Statutes Amendment Act, 2026) repealed the existing Daylight Saving Time Act and replaced it with the Official Time Act (Chapter O-5.7), locking in UTC-6 as standard time. It received royal assent on May 14, 2026, and took effect the same day it was made — June 18 — via Order in Council 204/2026. A companion order issued the same day, OiC 206/2026, gave this time the official name "Alberta Time," with a sunset clause expiring June 30, 2031 — meaning the name's validity is to be reviewed at that point. The tzdb comment dryly adds that this naming regulation affects neither time calculations nor TZDB data.

Alberta's year-round -06 isn't actually an unfamiliar time. It's the same time neighboring Saskatchewan has used for decades — tzdb's America/Regina has ended in -6:00 - CST for a long time. Alberta has simply joined that group.

The Northwest Territories (NWT) hasn't gotten there yet. The territory's premier has said they'll follow if Alberta does, and has in fact announced the abolition, but since the legal process hasn't finished, 2026c carries this only as a comment, not as data. Below the zone definition for America/Inuvik there's a comment like this:

Zone America/Inuvik	0	-	-00	1953 # Inuvik founded
			-8:00	NT_YK	P%sT	1979 Apr lastSun  2:00
			-7:00	NT_YK	M%sT	1980
			-7:00	Canada	M%sT
# Assuming Northwest Territories follows Alberta in abolishing seasonal time
# changes, replace the above line with something like:
#			-7:00	Canada	M%sT	2026 Nov  1  2:00
#			-6:00	-	CST

It's a TODO planted in the database in advance — once the law passes, they'll uncomment it and ship a release. That's why a 2026d is already being signaled.

Vancouver's New Abbreviation Is MST — the Trouble with Picking Abbreviations

The legal name of BC's new standard time is Pacific Time. The natural abbreviation would be PT, but that's where the trouble starts — tzdb and POSIX require time zone abbreviations to be alphanumeric (or signed) and between 3 and 6 characters, and PT is one character short. Eggert notes in the comments that he asked the BC government about an abbreviation but never got a reply. So the tzdb comments are left with a candidate-by-candidate critique, as is.

The conclusion was MST. So the zone definition in 2026c looks like this:

Zone America/Vancouver	-8:12:28 -	LMT	1884
			-8:00	Vanc	P%sT	1987
			-8:00	Canada	P%sT	2026 Mar  9
			# Temporary hack; see above.
			-8:00	1:00	PDT	2026 Nov  1  2:00
			# End of temporary hack.
			-7:00	-	MST

Zone America/Edmonton	-7:33:52 -	LMT	1906 Sep
			-7:00	Edm	M%sT	1987
			-7:00	Canada	M%sT	2026 Jun 18
			# Temporary hack; see above.
			-7:00	1:00	MDT	2026 Nov  1  2:00
			# End of temporary hack.
			-6:00	-	CST

Vancouver becomes MST, Edmonton becomes CST. There is one practical lesson to take from this — time zone abbreviations are not identifiers. The assumption that PST means -08 and MST means Mountain Standard Time now breaks on Canada's west coast. If you have code that parses abbreviations or branches on them, now is the time to move to IANA zone IDs (America/Vancouver) instead.

Why tzdb Deliberately Carries a Wrong Transition Date — the CLDR 48.1 Constraint

You may have noticed something odd in the zone definitions above. BC's legal effective date is March 9 and Alberta's is June 18, yet the data has both transitioning at November 1, 02:00. That's the part marked "Temporary hack" in the comments.

The reason is spelled out in the tzdb comments. If you model this as "-07 standard time" starting March 9 the way the law says, CLDR 48.1 (2026-01-08) generates the display name for that span as "Pacific Standard Time" — an error exposed straight to the user, where the offset is -07 but the name reads as the -08 standard time. So tzdb, for now, left March 9 through November 1 as PDT (daylight time), the way it already was. In the comment's own words, this span is actually standard time, so strictly speaking this hack is wrong, but the UT offset is correct, and it sidesteps the CLDR constraint. The comment also notes the plan to remove the hack once November arrives, since there is no longer any reason to keep it.

The Alberta comment has one more layer — Alberta's hack is needed for CLDR 48.2 (2026-03-17) and below too, and since few platforms track minor CLDR releases, the practical effect of the two hacks is similar.

What makes this interesting is the direction it runs. The source of the data (tzdb) bent the data to fit the release cycle and constraints of its own consumer (CLDR/ICU). The actual supply chain for display names flows like this — tzdb defines offsets and transitions, CLDR attaches per-language display names, ICU bundles that into a library, and on top of that the browser's Intl API, Java, and Android show the time zone name. Per ICU's release notes, ICU 78.2 (2026-01-09) shipped with CLDR 48.1 + tzdata 2025c, ICU 78.3 (2026-03-17) shipped with CLDR 48.2 + tzdata 2026a, and ICU 79, slated for October, is planned to ship CLDR 49 + Unicode 18. Given that cycle, it is easy to see why the choice was to bend it temporarily until November.

Of course, it is not free. While the hack is alive, summer in Vancouver and Edmonton is legally standard time but isdst=1 in the data. Code that branches on tm_isdst, and UIs that display the abbreviation (PDT/MDT), will see a value that diverges from the law during that window. And at November 1, 02:00, there is a "ghost transition" where the offset does not change at all — PDT→MST, MDT→CST, a transition where only the name and isdst flip. If you have code that counts transition events or assumes an offset change happens at every transition, it is worth knowing that this kind of transition can exist.

Morocco Returns to +00 After Eight Years — and the Predictions Through 2087 Get Erased

Since October 2018, Morocco has run permanent +01 except for dropping to +00 during Ramadan, repeating two transitions every year. Per 2026c, that regime ends — the government repealed the 2018 decree with a June 25, 2026 decree (Decree No. 2.26.530), and Morocco returns to permanent +00 starting September 20, 2026, 02:00, with no DST. Western Sahara (Africa/El_Aaiun) goes along with it. The sources tzdb cites are the confirmed Morocco World News article and the official gazette (Bulletin Officiel No. 7521).

Zone Africa/Casablanca	-0:30:20 -	LMT	1913 Oct 26
			 0:00	Morocco	%z	1984 Mar 16
			 1:00	-	%z	1986
			 0:00	Morocco	%z	2018 Oct 28  3:00
			 1:00	Morocco	%z	2026 Sep 20  2:00
			 0:00	-	%z

This change came with an inconspicuous cleanup attached. Since Ramadan follows the Islamic calendar, its Gregorian-calendar dates shift every year, and tzdb had been carrying astronomically pre-calculated Ramadan transitions through the year 2087 as rules. The Morocco rules in 2026b's africa file ran 183 lines; in 2026c they are 57 — 126 lines of prediction rules for 2027 through 2087 were deleted wholesale. The simple fact that a time zone database was carrying 60 years of future predictions shows just how unusual a piece of data this is.

The remnants of these prediction rules make the symptoms of stale data strange, too. A system running 2026b or earlier past September 20 will compute Casablanca as +01, one hour fast. But the deleted old rules had a Ramadan prediction of "drops to +00 on 2027-02-07, then returns to +01 on 2027-03-14" — so for those five weeks it will accidentally be right again, before going wrong once more from mid-March. Bugs from stale tzdata can show up this intermittently.

The Quiet Default Changes in 2026a

If Canada and Morocco are the headline, March's 2026a was the release that changed defaults. Picking out just what matters to engineers, per the NEWS file:

• The right (leap-second-aware) TZif files were dropped from the default install. This is an alternate file set for environments where the system clock counts leap seconds (non-POSIX-compliant), and since it is barely used by major distributions, it was excluded from the default. The old default can be restored with make REDO=posix_right, and if you genuinely have a leap-second-counting clock, make REDO=right_only is recommended. For where leap seconds themselves are headed, see No Leap Second in 2026 — and the Negative One No System Has Ever Run.
• A new compile-time option, TZ_RUNTIME_LEAPS=0. It turns off runtime leap-second support — this complies with POSIX and reduces attack surface and cost, but gives up the leap-second feature of RFC 9636 (the TZif format standard).
• The TZif abbreviation space grew from 50 bytes to 256 bytes. Some files were already using 40 bytes, so there was not much headroom left. If you have an old custom TZif parser, this is a reason to check whether it assumes a 50-byte limit.
• Moldova's past was retroactively corrected. Moldova has transitioned on the EU schedule (forward at 03:00, back at 04:00) since 2022, but the data had incorrectly stayed at 02:00/03:00. This is the kind of fix that changes how past timestamps get interpreted in local time — a good example that tzdata updates do not only change the future.
• The posixrules mechanism, obsolete since 2019b, was removed entirely.

There is also one thread running through all three releases this year: hardening of zic (the zone compiler). Integer- and buffer-overflow fixes for malicious input kept landing across 2026a/b/c. The reproduction inputs listed in NEWS, things like Zone Ouch 0 - LMT 9223372036854775807, clearly look like they came out of fuzzing. Few systems compile time zone source files received from outside a trust boundary with zic, but it is a reminder that tzcode is part of the supply chain too. There was also a decision in the opposite direction — the "TZif path restriction for unprivileged processes (require regular files, reject .. paths)" that was hardened in 2025c did not take hold on FreeBSD, and was reverted in 2026c. It is a realistic snapshot of infrastructure maintenance: even security hardening only survives if the ecosystem accepts it.

When Does Your Stack Get 2026c — Two Deadlines

Shipping the release is not the end of the story. I checked the actual propagation speed (as of 2026-07-17; only what I directly verified from each project's commit and package history is listed).

A pattern emerges. Distributions and Go catch up within days; the JDK only reaches an actual JVM after its mainline merge rides a quarterly update release; and platforms that get their time zone data via ICU (browsers, some embedded systems) are tied to ICU's release cycle. Layer on top of that the build timing of container base images, the JVM's own tzdata copy, and per-runtime copies like pip's tzdata package, and it is not remotely rare for different processes on the same server to see different time zone data.

For this release, there are two deadlines worth putting on the calendar.

1. 2026-09-20, 02:00 — Morocco and Western Sahara. Systems that have not updated by then will compute +01 afterward, one hour fast.
2. 2026-11-01, 02:00 — BC and Alberta. Stale data will run a fall-back transition that no longer exists, dropping Vancouver to -08 and Edmonton to -07. After that, they will run one hour slow. Once NWT's legislation is finished, a third item may be added alongside a 2026d.

You can check right away, with zdump, which side your system is on.

# If 2026c is applied: you'll see the September 20 +01 -> +00 transition
zdump -v Africa/Casablanca | grep 2026

# If 2026c is applied: gmtoff stays at -21600 across the November 1 transition (MDT -> CST)
# If the data is stale: gmtoff drops from -21600 -> -25200 (MDT -> MST)
zdump -v America/Edmonton | grep 2026

Conversely, there are clearly cases where this does not matter this time around. If your service only serves Korean users, KST is unaffected by this release, and a backend that only stores and computes past timestamps in UTC will not break from the offset change alone. Three things are actually at risk — future local-time schedules in the affected regions (if you convert a "Casablanca 09:00 meeting" after September 20 to UTC using stale data and store it, it will fire at the wrong moment, off by an hour), local-time displays shown to users, and any logic that depends on isdst or on the abbreviation.

Closing

tzdb is an unusual piece of infrastructure where politics is the input and data is the output. This year's input was legislation from two Canadian provinces and a decree from Morocco; the output was three releases (soon to be four), and one deliberately wrong date kept in place until November for the sake of the CLDR ecosystem. To summarize:

• BC (March 9) and Alberta (June 18) are already legally on permanent time, but tzdb carries them with a November 1 transition to work around CLDR 48.x — the offset is correct throughout.
• Morocco and Western Sahara are on permanent +00 starting September 20, 02:00. tzdata 2026c needs to be deployed fleet-wide before then.
• Code that depends on time zone abbreviations (assumptions like PST=-08) or on tm_isdst actually breaks this cycle. Compute with the zone ID and offset, and use the abbreviation for display only.

The less anyone reads the release notes for a piece of infrastructure, the more its existence only becomes visible after an hour has already gone missing. One line of zdump is enough to know in advance.

References

• IANA Time Zone Database — official page (2026c, 2026-07-08)
• tz NEWS file — original release notes for 2026a/2026b/2026c
• northamerica source file (2026c) — zone definitions and comments for BC, Alberta, and NWT
• africa source file (2026c) — zone definitions for Morocco and Western Sahara
• tz-announce mailing list archive
• BC government announcement — Adopting permanent daylight saving time (2026AG0013)
• Morocco World News — Morocco to Restore GMT on September 20 (source cited by tzdb)
• ICU releases — notes for 78.2 (CLDR 48.1) and 78.3 (CLDR 48.2)
• OpenJDK — tzdata VERSION update commit history (JDK-8383175 and others)
• Go — lib/time update commit history (2026c: July 9)
• Debian tzdata package tracker
• Timestamps and Time Zones, Done Right (related post)
• No Leap Second in 2026 — and the Negative One No System Has Ever Run (related post)