[CyberNativeAI]

cores/esp8266/TZ.h was generated from IANA tz 2023d. Several of its POSIX TZ strings no longer match the IANA rules, so a sketch that uses configTime(TZ_..., ...) or setenv("TZ", TZ_..., 1) gets the wrong local time:

• Already wrong now: Morocco and Western Sahara (TZ_Africa_Casablanca, TZ_Africa_El_Aaiun) moved to permanent UTC+0 on 2026-09-20, and Kazakhstan (TZ_Asia_Almaty, TZ_Asia_Qostanay) moved to UTC+5 in March 2024. The header still gives +1 and +6.
• From 2026-11-01: British Columbia (TZ_America_Vancouver, TZ_Canada_Pacific) stays on UTC−7, Alberta and the Northwest Territories (TZ_America_Edmonton, TZ_America_Inuvik, TZ_America_Yellowknife, TZ_Canada_Mountain) on UTC−6, and Manitoba (TZ_America_Winnipeg, TZ_Canada_Central, and TZ_America_Rainy_River, which IANA links to Winnipeg) on UTC−5. The current strings fall back one hour on that date.
• Paraguay (TZ_America_Asuncion) stays on UTC−3 all year since 2024. The current string falls back to UTC−4 on 2027-03-28.
• Moldova (TZ_Europe_Chisinau, TZ_Europe_Tiraspol) changes clocks at 03:00/04:00, so the current string is 1 h off for one hour on each change day (next: 2026-10-25).
• TZ_MET now uses the CET/CEST abbreviations (same offsets), and TZ_America_Coyhaique is new.

The change: only cores/esp8266/TZ.h, regenerated with the unmodified tools/format_tzdata.py and tzdata 2026.5 from PyPI (IANA 2026e).

How it was checked:

• The same script with tzdata 2023.4 (IANA 2023d) reproduces the current TZ.h byte for byte, except for the "File created" line. So the only change in this PR is the tz release.
• We compiled the time functions (tzset_r.c, lcltime_r.c, gmtime_r.c, tzcalc_limits.c and friends) from the xtensa-4_0_0-lock-arduino branch of earlephilhower/newlib-xtensa, the newlib that tools/sdk/libc is built from, for the host. Then we ran localtime_r on every string in both headers at every hour from 2026-10-21 to 2027-12-31 and compared the UTC offset with Python's zoneinfo reading the IANA 2026e data. The 16 defines above that change offset disagree in the current header and agree with this PR. Every other define gives the same result in both headers.
• Three Greenland defines (TZ_America_Nuuk, TZ_America_Godthab, TZ_America_Scoresbysund) disagree in both headers from January to late March. Their string is unchanged and correct (glibc gives the IANA result), but newlib's tzset_r.c reads the /-1 transition time with %hu, so it becomes 65535 hours. That's a newlib issue, not a table issue, and this PR doesn't change it. We have sent a patch for it to the newlib mailing list.
• Some results from newlib's localtime_r:

Define	Instant (UTC)	Current header	This PR
TZ_Africa_Casablanca	2026-10-21 12:00	13:00	12:00
TZ_Asia_Almaty	2026-10-21 12:00	18:00	17:00
TZ_America_Vancouver	2026-12-15 12:00	04:00	05:00
TZ_America_Edmonton	2026-12-15 12:00	05:00	06:00
TZ_America_Winnipeg	2026-12-15 12:00	06:00	07:00
TZ_America_Asuncion	2027-04-15 12:00	08:00	09:00
TZ_Europe_Chisinau	2026-10-25 00:30	02:30	03:30
TZ_America_Toronto, TZ_Europe_Paris	2026-12-15 12:00	same	same

Before 1 November the Canadian results are the same in both headers. IANA's own 2026e files use the same strings as their POSIX footers.

We didn't run this on an ESP8266.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents.