sql: fork chrono-tz to deliver tzdata 2026c

[ohbadiah]

Ship IANA tzdata 2026c by pointing the workspace at a MaterializeInc fork of chrono-tz.

Motivation

Upstream chrono-tz stops at 0.10.4 with tzdata 2025b and its maintainer is winding the project down, so newer IANA data will not arrive from crates.io. Under 2025b, Materialize starts giving wrong answers about the present on 2026-09-20, when Morocco moves to permanent +00, and again on 2026-11-01, when Alberta and British Columbia would appear to fall back but no longer do.

The fork

MaterializeInc/chrono-tz is forked at the v0.10.4 tag. Its mz_changes branch carries exactly two commits: bump the tz submodule to the IANA 2026c tag, and regenerate the crate's prebuilt data with its own codegen test. No code changes, same API, same phf 0.12, so the existing deny.toml exception and every call site are untouched. Upstream main has unreleased semver-breaking changes, which is why the fork is cut from the tag rather than from main. The [patch.crates-io] entry pins the rev. chrono-tz-build and parse-zoneinfo are path dependencies inside that repo, so they follow automatically.

Data changes 2025b to 2026c

Transition-level diff of every zone the prebuilt data touches:

Zones	Change	Past instants affected
Africa/Casablanca, Africa/El_Aaiun	Permanent +00 from 2026-09-20	none
America/Edmonton, America/Yellowknife, Canada/Mountain	Permanent -06, no 2026-11-01 fall-back, abbreviation CST	none
America/Vancouver, Canada/Pacific	Permanent -07, no 2026-11-01 fall-back, abbreviation MST	none
Europe/Chisinau, Europe/Tiraspol	EU transition instants since 2022, one hour later than before	nine one-hour windows, 2022-03-27 to 2026-03-29
America/Tijuana and links	DST observed 1953 and 1961 to 1975	32 transitions, all before 1976

The zone directory is unchanged, so no zone appears, disappears, or renames.

Ingestion exposure

Same analysis as the 2025b bump. Every abbreviation these zones can render on the PostgreSQL wire (EET, EEST, MST, MDT, CST, PST, PDT) is a fixed-offset entry in src/pgtz/tznames/Default, and Morocco renders numeric offsets. None of the dynamic abbreviation links point at a changed zone. A retraction re-parsed from upstream text therefore resolves to the same instant under either data version, regardless of upstream DateStyle. The residual is a user-written ingestion expression naming Europe/Chisinau outright and landing in one of the nine past hours.

Tests

• src/environmentd/tests/testdata/timezones/regenerate.sh now pins 2026c, and names-2026-12-15.csv is regenerated. Seven rows changed, exactly the Moroccan and Canadian zones. The June snapshot and both abbrevs snapshots are unchanged. The differential test fails against the old snapshots on exactly those seven zones and passes against the new ones.
• test/sqllogictest/timezone.slt gains a present-day block at wall time 2026-12-15 for Casablanca, Edmonton, Vancouver, and Chisinau, timezone_offset checks for the three permanent-offset zones, and a history pin asserting the 2023-03-26 Chisinau window resolves under the EU instant.

Suggested review order

1. Cargo.toml: the patch line and its comment.
2. Cargo.lock: three entries move from the registry to the git source, nothing else.
3. src/environmentd/tests/testdata/timezones/: the version bump and the seven changed snapshot rows.
4. test/sqllogictest/timezone.slt: the new pins.

Release note

This release will ship IANA tzdata 2026c, updating time zone rules for Morocco (permanent +00 from 2026-09-20), Alberta (permanent -06), British Columbia (permanent -07), and Moldova (EU transition instants since 2022).

Closes: SQL-570

🤖 Generated with Claude Code

[martykulma]

The CI failure appears to be unrelated.

Agree that the transition from 2025b -> 2026c doesn't appear to carry any exposure for sources. We still don't force an ISO DateStyle in the connection to PG, but it doesn't matter here due to src/pgtz/tznames/Default ( as mentioned in the description ).

Claude did point out that there is impact beyond sources:

1. query-time eval - AT TIME ZONE, timezone(), date_trunc(_, _, tz) take a literal IANA name straight to chrono-tz. Persisted MV/index results over pre-2026 data at Chisinau/Tiraspol or the Baja zones recompute differently on rehydration.

2. client input - timestamptz '1970-07-15 12:00:00 America/Tijuana' via INSERT, COPY FROM, or a pgwire text param resolves a full zone name through chrono-tz.

Need to confirm impact there.

[martykulma]

should add a similar test for America/Tijuana which retroactively updated DST

[martykulma]

I don't see how a client command could cause a negative retraction - COPY FROM is additive, update retracts the actual old row (doesn't use the literal for the retraction), and deletes would just apply to new timestamps (expected).

I think compute is also unaffected, as it would self-correct and issue retractions/corrections, but I defer to someone on the compute team.

lgtm otherwise!

[ohbadiah]

I think compute is also unaffected, as it would self-correct and issue retractions/corrections, but I defer to someone on the compute team.

That's also my understanding, and previous updates to tzdata (including the much bigger correction shipped in July) did not cause any issues in Compute. Still, deferring to @antiguru for (I hope) a quick review.