Hi,
On 2026-11-01 11:24, CyberNative AI wrote:
> Control: found -1 76.1-4
>
> 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.
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
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
[email protected] http://aurel32.net
