Description of problem: For a while tzdata has shipped /usr/share/zoneinfo/tzdata.zi which gives us $ head -n1 /usr/share/zoneinfo/tzdata.zi # version 2021e php could parse the first line of this file and use it as the "real" Olson database version rather than the synthetic "0.system" placeholder. Version-Release number of selected component (if applicable): php-8.0.15-1.fc35.x86_64
Thanks for the notice, I miss this new file. Make sense Minor tweak, tzdata set version as 2021e, while php expected 2021.5 Work is ready in my repo for PHP 8.1: https://git.remirepo.net/cgit/rpms/php/php81.git/commit/?id=e019ac5b39addf41c684bcfc58718113439e1ef6 PHP 8.0: https://git.remirepo.net/cgit/rpms/scl-php80/php.git/commit/?id=d102862ce98fa02a2ba31ae051e631d3f9640d0b Plan: - apply change in rawhide (8.1) with PHP 8.1.4RC1 (March 3rd) - apply change in F35+ (8.1 and 8.1) with 8.1.4 and 8.0.17 (March 17th)
Previous: $ php --ri date date date/time support => enabled timelib version => 2020.03 "Olson" Timezone Database Version => 0.system Timezone Database => internal Default timezone => UTC Directive => Local Value => Master Value date.timezone => UTC => UTC date.default_latitude => 31.7667 => 31.7667 date.default_longitude => 35.2333 => 35.2333 date.sunset_zenith => 90.833333 => 90.833333 date.sunrise_zenith => 90.833333 => 90.833333 New: $ php --ri date date date/time support => enabled timelib version => 2020.03 "Olson" Timezone Database Version => 2021.5 Timezone Database => system Default timezone => UTC Directive => Local Value => Master Value date.timezone => no value => no value date.default_latitude => 31.7667 => 31.7667 date.default_longitude => 35.2333 => 35.2333 date.sunset_zenith => 90.833333 => 90.833333 date.sunrise_zenith => 90.833333 => 90.833333 So * "Olson" Timezone Database Version change from 0;system to 2021.5 * Timezone Database change from internal to system
Very nice patch, thanks Remi.
Side note: will also work on RHEL where tzdata.zi contains "# version 2021e-rearguard" (version suffix will be ignored)
FEDORA-2022-58f4383ca4 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-58f4383ca4
FEDORA-2022-58f4383ca4 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-58f4383ca4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-58f4383ca4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-302edd8c16 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-302edd8c16
FEDORA-2022-302edd8c16 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-302edd8c16` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-302edd8c16 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-302edd8c16 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-58f4383ca4 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.