tzdata 2026c — カナダは時計を止め、モロッコはGMTへ戻る

はじめに — 誰もリリースノートを読まないインフラの、7月8日
今年の3リリース — ひと目で
カナダ西部が時計を止めた
バンクーバーの新しい略語はMST — 略語を選ぶことの難しさ
tzdbがあえて「不正確な」移行日を載せた理由 — CLDR 48.1の制約
モロッコ、8年ぶりの+00復帰 — そして2087年までの予測が消えた
2026aの静かなデフォルト変更
あなたのスタックはいつ2026cを受け取るか — 2つの締め切り
おわりに
参考資料

はじめに — 誰もリリースノートを読まないインフラの、7月8日

2026年7月8日、IANAタイムゾーンデータベースの今年3回目のリリース、tzdata 2026cが出ました。このデータベースは地球上のあらゆるタイムゾーンのUTCオフセット、移行ルール、そして過去の変更履歴を収めたテキストファイル群であり、皆さんのスタックのどこかに必ず入っています — glibcが読む /usr/share/zoneinfo、JDKが持ち歩く独自コピー、Go標準ライブラリに埋め込まれたコピー、そしてICUを経由してブラウザ・Node・Androidまで。

このデータが更新される理由はいつも同じです。どこかの政府が時間に関する法律を変えたからです。今年はその入力がとりわけ大きなものでした — カナダの2州(そしてまもなく3つ目の準州も)が季節ごとの時計変更を廃止し、モロッコが8年ぶりにGMTへ戻ることを決めました。その過程で、tzdbがCLDRの制約のために法的発効日とは異なる移行日をあえて載せる、珍しい出来事も起きました。

本稿では今年の3つのリリース(2026a/2026b/2026c)が実際に変えたものを、一次情報源(NEWSファイルとzoneデータ)に基づいて追い、秋に控える2つの締め切りの前に何を点検すべきかを整理します。タイムゾーン・タイムスタンプの一般論はすでにタイムスタンプとタイムゾーンを正しく扱うで扱ったので、ここでは2026年に実際に変わったものだけを見ます。

今年の3リリース — ひと目で

リリース	日付	主な変更
2026a	2026-03-01	モルドバの過去データの遡及修正、right(閏秒反映)ファイルをデフォルトインストールから除外、TZif略語スペース50→256バイト
2026b	2026-04-22	ブリティッシュコロンビア恒久-07、zicオーバーフロー修正
2026c	2026-07-08	アルバータ恒久-06、モロッコが9月20日付で恒久+00、zicオーバーフロー追加修正

tzdataは定期リリースではなく「必要なとき」に出ます。直近3年(2023〜2025)はそれぞれ4回・2回・3回で、今年は7月ですでに3回目です。そしてNEWSファイルが予告するとおり、ノースウェスト準州の件で「まもなくもう一度リリースが必要になる可能性が高い」状態です。

カナダ西部が時計を止めた

ブリティッシュコロンビア(BC)が最初でした。BC州政府の発表(2026AG0013)によれば、2026年3月8日の春の切り替え(spring forward)が最後の時計変更で、以降BCは年間を通じて-07にとどまります。法律の文言が興味深く、tzdbの注釈に引用されたPaul Eggertの整理によれば「3月8日02:00の通常のPST→PDT移行から21時間後の翌日(3月9日00:00)から新しい標準時Pacific Timeが始まる」とされています。つまり時計変更は1回なのに、名称変更は21時間の間隔を置いて2回起きる構造です。

アルバータが続きました。経緯はかなり官僚的に興味深いものです — Bill 31(Red Tape Reduction Statutes Amendment Act, 2026)の第3節が既存のDaylight Saving Time Actを廃止してOfficial Time Act(Chapter O-5.7)に置き換え、UTC-6を標準時と定めました。2026年5月14日に国王裁可を受けたのち、6月18日にOrder in Council 204/2026として同日発効しています。同日出されたOiC 206/2026はこの時間の正式名称を「Alberta Time」と定めましたが、この規定には2031年6月30日の失効条項が付いています — その時点で名称の妥当性を再検討する、という意味です。tzdbの注釈はこの名称規定が「時間計算にもTZDBデータにも影響しない」とそっけなく付け加えています。

アルバータの年間-06は、実は見慣れない時間ではありません。隣のサスカチュワンが数十年前から使っているのと同じ時間で、tzdbのAmerica/Reginaは以前から-6:00 - CSTで終わります。アルバータはその仲間に加わったわけです。

ノースウェスト準州(NWT)はまだです。準州首相は「アルバータが実施すれば追随する」と表明しており、実際に廃止を発表していますが、法的手続きが終わっていないため2026cにはデータとしてではなく注釈としてのみ入っています。America/Inuvikのzone定義の下には、こんな注釈が付いています。

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

法律が通れば注釈を外してリリースする、というデータベースにあらかじめ埋め込まれたTODOです。2026dが予告されている理由です。

バンクーバーの新しい略語はMST — 略語を選ぶことの難しさ

BCの新しい標準時の法的名称はPacific Timeです。自然な略語はPTですが、ここで問題が生じます — tzdbとPOSIXはタイムゾーン略語を英数字(または符号)3文字以上6文字以下と定めており、PTは1文字足りません。EggertはBC州政府に略語を問い合わせたものの返答を得られなかったと注釈に記しています。そのためtzdbの注釈には候補ごとの品評がそのまま残されています。

候補	tzdb注釈の評価
MST	既存のソフトウェア・慣行と最も互換性がある。BCの一部地域とユーコンはすでに-07でこの略語を使用
PDT	ほぼ問題ないが、実際には標準時であるのにDSTだと誤解される
PST	直感的だが、より混乱を招き、PSTが-08だと仮定するソフトウェアを壊す可能性
-07	それ自体は正確だが、隣接地域と並べると不自然
PacT	直感的だが、前例のない新しい略語

結論はMSTでした。そのため2026cのzone定義はこうなっています。

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

バンクーバーがMST、エドモントンがCSTになります。ここから得られる実務上の教訓は一つです — タイムゾーンの略語は識別子ではありません。 PSTは-08、MSTは山岳部標準時だという前提は、いまやカナダ西海岸で崩れます。略語をパースしたり略語で分岐したりするコードがあるなら、今こそIANAのzone ID(America/Vancouver)へ移行するときです。

tzdbがあえて「不正確な」移行日を載せた理由 — CLDR 48.1の制約

上のzone定義で奇妙な点に気づいたはずです。BCの法的発効日は3月9日、アルバータは6月18日なのに、データはどちらも11月1日02:00に移行することになっています。注釈に「Temporary hack」と書かれている箇所です。

理由はtzdbの注釈に明記されています。法的な日付どおり3月9日から「-07標準時」としてモデル化すると、CLDR 48.1(2026-01-08)がこの区間の表示名を「Pacific Standard Time」にしてしまいます — オフセットは-07なのに、名称は-08の標準時として表記される、ユーザーにそのまま露出する誤りです。そのためtzdbは3月9日から11月1日までを、これまでどおりPDT(サマータイム)のままにしました。注釈の表現を借りれば、この区間は実際には標準時なので厳密に言えばこのhackは間違っているが、UTオフセットは正確であり、CLDRの制約を回避するということです。11月になればhackを維持する理由自体がなくなるので、そのとき削除できるだろうという計画も併記されています。

アルバータ側の注釈にはもう一段あります — アルバータのhackはCLDR 48.2(2026-03-17)以下でも必要で、「マイナーCLDRリリースを追う環境は少数派なので、2つのhackの実質的な効果は似たようなものだ」とされています。

この出来事が興味深いのは向きです。データの源(tzdb)が、消費者(CLDR/ICU)のリリース周期と制約に合わせてデータを曲げたのですから。実際、表示名のサプライチェーンはこう流れます — tzdbがオフセットと移行を定義し、CLDRが言語別の表示名を付け、ICUがそれをライブラリにまとめ、その上でブラウザのIntl API・Java・Androidがタイムゾーン名を表示します。ICUのリリースノートによれば、ICU 78.2(2026-01-09)はCLDR 48.1 + tzdata 2025cを、ICU 78.3(2026-03-17)はCLDR 48.2 + tzdata 2026aを載せており、10月予定のICU 79はCLDR 49 + Unicode 18を載せる計画です。この周期を踏まえると、「11月まで一時的に曲げる」という選択がなぜ出てきたのか納得がいきます。

もちろんタダではありません。hackが生きている間、バンクーバーとエドモントンの夏は法的には標準時なのにデータ上はisdst=1です。tm_isdstの値で分岐するコードや、略語(PDT/MDT)を表示するUIは、その間ずっと法とは異なる値を見ることになります。そして11月1日02:00には、オフセットが変わらない「幽霊移行」が一つ起きます — PDT→MST、MDT→CSTと、名称とisdstだけが変わる移行です。移行イベントを数えたり、移行のたびにオフセットが変わると仮定したりするコードがあるなら、こうした移行が存在しうることも知っておく価値があります。

モロッコ、8年ぶりの+00復帰 — そして2087年までの予測が消えた

モロッコは2018年10月から常時+01を使いつつ、ラマダン期間だけ+00に下げるという、毎年2回の移行を繰り返してきました。2026cによればこの体制が終わります — 政府が2026年6月25日の勅令(Decree No. 2.26.530)で2018年の勅令を廃止し、2026年9月20日02:00から恒久的な+00、DSTなしに戻ります。西サハラ(Africa/El_Aaiun)も同様です。tzdbが引用する報道はMorocco World Newsの確定記事と官報(Bulletin Officiel第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

そしてこの変更には、目につきにくい大掃除がついてきました。ラマダンはイスラム暦に従うため毎年グレゴリオ暦上の日付が移動しますが、tzdbはこれまで天文計算によって2087年までのラマダン移行をあらかじめ計算し、ルールとして載せてきました。2026bのafricaファイルにはMoroccoルールが183行ありましたが、2026cでは57行です — 2027年から2087年までの予測ルール126行がまるごと削除されました。タイムゾーンデータベースが60年分の未来予測を抱えていたという事実自体が、このデータがいかに特異な代物かを物語っています。

この予測ルールの残滓は、古いデータの症状もまた奇妙にします。2026b以下のデータで9月20日を過ぎたシステムは、カサブランカを+01として計算し、1時間早く表示します。ところが削除された旧ルールには「2027-02-07に+00へ下がり、2027-03-14に+01へ復帰」というラマダン予測があったため、その5週間だけは偶然また正しくなり、3月中旬から再び間違うことになります。古いtzdataのバグはこのように断続的に現れることがあります。

2026aの静かなデフォルト変更

カナダとモロッコが見出しだとすれば、3月の2026aはデフォルトを変えたリリースでした。NEWSを基にエンジニアにとって意味のあるものだけを拾うと、こうなります。

right(閏秒反映)TZifファイルがデフォルトインストールから外れました。 システムクロックが閏秒を数える(POSIX非準拠の)環境向けの代替ファイル一式で、主要ディストリビューションでほとんど使われていないためデフォルトから除外されました。旧デフォルトはmake REDO=posix_rightで復元でき、本当に閏秒を数えるクロックならmake REDO=right_onlyが推奨されます。閏秒そのものがどこへ向かっているかは2026年も閏秒なし — そして誰も動かしたことのない負の閏秒を参照してください。
コンパイルオプションTZ_RUNTIME_LEAPS=0が追加されました。ランタイムの閏秒サポートを切るオプションで、POSIXには適合し攻撃対象と費用を減らしますが、RFC 9636(TZifフォーマット標準)の閏秒機能は諦めます。
TZif略語スペースが50バイトから256バイトへ拡張されました。一部のファイルはすでに40バイトを使っていたため、余裕はあまりなかったわけです。古い独自TZifパーサーがあるなら、50バイトという前提を確認する理由ができました。
モルドバの過去が遡及修正されました。 モルドバは2022年からEU方式(03:00前進、04:00後退)で移行してきましたが、データは02:00/03:00のまま誤って残っていました。過去のタイムスタンプの現地時刻解釈が変わる種類の修正です — tzdataの更新が未来だけを変えるわけではない好例です。
2019bからobsoleteだったposixrulesの仕組みが完全に削除されました。

そして今年の3リリースを貫く流れがもう一つあります。zic(ゾーンコンパイラ)のハードニングです。悪意ある入力に対する整数・バッファオーバーフローの修正が2026a/b/cにわたって継続して入りました。NEWSに載った再現入力はZone Ouch 0 - LMT 9223372036854775807のような、明らかにファジングから出てきた形をしています。信頼境界の外から受け取ったタイムゾーンソースファイルをzicでコンパイルするシステムは少ないでしょうが、tzcodeもサプライチェーンの一部だという点を思い出させてくれます。逆方向の決定もありました — 2025cで強化していた「非特権プロセスのTZifパス制限(通常ファイルの強制、..パスの拒否)」はFreeBSDで定着せず、2026cで元に戻されました。セキュリティ強化もエコシステムが受け入れて初めて維持される、というインフラ保守の現実的な一面です。

あなたのスタックはいつ2026cを受け取るか — 2つの締め切り

リリースが出て終わりではありません。実際の伝播速度を確認しました(2026-07-17時点、各プロジェクトのコミット・パッケージ履歴から直接確認したものだけを記載します)。

経路	状況
Go(golang/go lib/time)	リリース翌日の7月9日に2026cをマージ
Debian(tzdataパッケージ)	2026c-1のパッケージング完了
Fedora	直近のstable更新は2026b-1(5月20日)
OpenJDKメインライン	2026bまでマージ済み(4月27日、JDK-8383175)。2026cは本稿執筆時点で未マージ
ICU	最新のメンテナンス版78.3(3月17日)がtzdata 2026aを同梱

パターンが見えます。ディストリビューションとGoは数日単位で追いつき、JDKはメインラインへのマージ後、四半期ごとのアップデートリリースを経てようやく実際のJVMに届き、ICU経由でタイムゾーンデータを受け取るプラットフォーム(ブラウザ、一部の組み込み機器)はICUのリリース周期に縛られます。ここにコンテナベースイメージのビルド時点、JVM独自のtzdataコピー、pipのtzdataパッケージのようなランタイムごとのコピーが重なると — 同じサーバー上でプロセスごとに異なるタイムゾーンデータを見る事態は、まったく珍しくありません。

今回のリリースを基準に、カレンダーに書いておくべき締め切りは2つです。

2026-09-20 02:00 — モロッコ・西サハラ。 それまでに更新していないシステムは、以降+01として計算し、1時間早く表示します。
2026-11-01 02:00 — BC・アルバータ。 古いデータは存在しない秋の切り替え(fall back)を実行し、バンクーバーを-08に、エドモントンを-07に落とします。以降は1時間遅くなります。NWTの立法が終われば、2026dとともに3つ目の項目が加わるかもしれません。

自分のシステムがどちら側かはzdumpですぐ確認できます。

# 2026cが適用済みなら: 9月20日の+01 -> +00移行が見える
zdump -v Africa/Casablanca | grep 2026

# 2026cが適用済みなら: 11月1日の移行でgmtoffが-21600のまま維持される (MDT -> CST)
# 古いデータなら: gmtoffが-21600 -> -25200へ落ちる (MDT -> MST)
zdump -v America/Edmonton | grep 2026

逆に、今回は気にしなくてよいケースも明確にあります。韓国のユーザーだけを相手にするサービスなら、KSTは今回のリリースと無関係ですし、過去のタイムスタンプをUTCで保存・演算するだけのバックエンドは、オフセット変更そのものでは壊れません。危険なのは3つです — 該当地域の未来の現地時刻スケジュール(9月20日以降の「カサブランカ09:00の会議」を古いデータでUTC変換して保存すると、1時間ずれた瞬間に発火します)、ユーザーに見せる現地時刻表示、そしてisdstや略語に依存するロジックです。

おわりに

tzdbは「政治が入力で、データが出力」という特異なインフラです。今年の入力はカナダ2州の法律とモロッコの勅令で、出力は3回(まもなく4回)のリリース、そしてCLDRエコシステムのために11月まで維持される、自発的な「不正確な日付」一つでした。まとめると、

BC(3月9日)とアルバータ(6月18日)は法的にはすでに恒久時間ですが、tzdbにはCLDR 48.xの回避のため11月1日移行として載っており、オフセットはずっと正確です。
モロッコ・西サハラは9月20日02:00から恒久+00です。それより前にtzdata 2026cが全システムに行き渡っている必要があります。
タイムゾーン略語(PST=-08のような前提)とtm_isdstに依存するコードは、この周期で実際に壊れます。zone IDとオフセットで計算し、略語は表示専用にとどめてください。

誰もリリースノートを読まないインフラほど、1時間が消えたあとになって初めてその存在が明らかになります。zdump一行で事前に知ることができます。