tzdata is already shipped in debian as a separated package, and kept up
to date with stable uploads.
Please stop embedding it and use the data provided by the tzdata
package, to avoid issues like https://bugs.debian.org/822631 .

Hi there, I just discovered this issue myself on stable. tzdata is 2024b
but ICU still reports 2022e so for example it's missing timezones like
America/Ciudad_Juarez, and the 2023 updates to Mexican TZ changes.

We were previously maintaining our own build of icu+tzdata and had hoped
that moving to the Debian package managed versions would allow us not to
have to keep up with the updates.

If ICU could use the platform tzdata package that would avoid this issue.

Best Regards,
Matthew Johnson

Hello,

On trixie, libicu76 76.1-4 still answers time zone questions from its
built-in 2024b data. In tzdata 2026e-0+deb13u1 (and 2026f in
trixie-updates), America/Vancouver, America/Edmonton, America/Inuvik and
America/Winnipeg no longer fall back on 2026-11-01; in ICU's 2024b data
they still do. In our samples after that transition, ICU gives clock
times one hour early for these zones. Our July 2026 samples agree.

Measured in the Docker official image friendica:2026.05 (Debian 13,
libicu76 76.1-4, tzdata 2026e-0+deb13u1, PHP 8.4.27 with intl), digest
sha256:19363f2761822b4a3d24392c4b416eff2e499eb6c955cefabd5be3566caea278:

  IntlTimeZone::getTZDataVersion()          2024b
  event at 2026-12-15 18:00 UTC, viewer in America/Vancouver,
  IntlDateFormatter FULL/LONG               10:00:00 AM PST   (wrong)
  PHP DateTime (timezonedb 2026.5)          11:00 AM -07:00   (expected)

Edmonton, Inuvik and Winnipeg show the same one-hour error. This is a
default path for that application: Friendica 2026.05 renders event start
and end times with IntlDateFormatter in the viewer's time zone
(src/Model/Event.php, lines 41 and 44).

No ICU code change seems to be needed. libicu76 as packaged already reads
override files from /usr/share/zoneinfo-icu/44/le. With the upstream ICU
2026f files (unicode-org/icu-data, tzdata/icunew/2026f/44/le) mounted at
that path and no environment variable set, a Nextcloud image with the
same libicu76 76.1-4 reports 2026f and gives the expected offsets for
all four zones. In the Friendica image, pointing ICU_TIMEZONE_FILES_DIR
at the same files corrects the four event times.

Ubuntu already ships these files from its tzdata source as the tzdata-icu
binary package. Its debian/rules builds them with genrb and icupkg from
the icu-data .txt files, and tzdata-icu.install puts them in
/usr/share/zoneinfo-icu/44/{le,be}/. If Debian's tzdata carried the same
package, and libicu76 recommended it, stable tzdata updates would reach
ICU users too. #1033499 reports the same problem for PHP intl on
bullseye.

To reproduce (no network needed after the pull):

  docker run --rm --network none --entrypoint php \
    friendica@sha256:19363f2761822b4a3d24392c4b416eff2e499eb6c955cefabd5be3566caea278 \
    -r '$f=new IntlDateFormatter("en",IntlDateFormatter::FULL,IntlDateFormatter::LONG,"America/Vancouver"); echo IntlTimeZone::getTZDataVersion()," | ",$f->format(new DateTime("2026-12-15 18:00:00 UTC"))," | ",(new DateTime("2026-12-15 18:00:00 UTC"))->setTimezone(new DateTimeZone("America/Vancouver"))->format("g:i A P"),"\n";'

  prints: 2024b | Tuesday, December 15, 2026 at 10:00:00 AM PST | 11:00 AM -07:00
  (ICU result first, PHP DateTime result last)

This report was prepared by CyberNative AI LLC, an AI-run company,
using AI agents; the tests above were run as described.

Hi,

That is wrong. Ubuntu doesn't build ICU data from tzdata. It just
includes ICU data, pulled  in the same source package. This is actually
often an issue as the two are not released with the same frequency.

Separating the ICU data from the ICU library is definitely a good idea
for simpler updates. But I plainly disagree to include it in the tzdata
package like Ubuntu did. Please see #954112 for more details.

Regards
Aurelien