Hi!
As you might be aware, I maintain the date time support in PHP. As part
of that I regularly have to update the rules that timezones employ -
changes in Daylight Saving Time rules, or other changes to rules due to
political foibles.
In the last few years, the maintainer of the Iana TZ Data project has
diverged somewhat from the consensus of the community, and degraded some
data by no longer having an entry for each country and merged timezones
where data does not differ since 1970. (Removing transitions from these
regions where data does differ before 1970, even if these were
available).
Java's date/time maintainer has created a fork based on the original
Iana TZ data to put back some of the removed/deprecated data to better
serve their users, and I would think that this is also best suited as a
data set for PHP.
If you want to read about the intricacies, see:
https://github.com/JodaOrg/global-tz#rationale
But this does mean a divergence from the "official" TZ data, although
Joda's data is arguably better. My recommendation is that from the 2022b
release we switch to Joda's version. (I will today merge in the 2022a
data from the Iana source.)
Comments?
If you want to discuss this live, come find me in "Room 11":
https://chat.stackoverflow.com/rooms/11/php
cheers,
Derick
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug
Hi!
As you might be aware, I maintain the date time support in PHP. As part
of that I regularly have to update the rules that timezones employ -
changes in Daylight Saving Time rules, or other changes to rules due to
political foibles.In the last few years, the maintainer of the Iana TZ Data project has
diverged somewhat from the consensus of the community, and degraded some
data by no longer having an entry for each country and merged timezones
where data does not differ since 1970. (Removing transitions from these
regions where data does differ before 1970, even if these were
available).Java's date/time maintainer has created a fork based on the original
Iana TZ data to put back some of the removed/deprecated data to better
serve their users, and I would think that this is also best suited as a
data set for PHP.If you want to read about the intricacies, see:
https://github.com/JodaOrg/global-tz#rationaleBut this does mean a divergence from the "official" TZ data, although
Joda's data is arguably better. My recommendation is that from the 2022b
release we switch to Joda's version. (I will today merge in the 2022a
data from the Iana source.)Comments?
If you want to discuss this live, come find me in "Room 11":
https://chat.stackoverflow.com/rooms/11/phpcheers,
Derick
Keeping in mind that people deploying PHP on Linux usually end up using
OS-provided zoneinfo, do you know which source distros base that on? I
think we should follow the distro-consensus here, whatever that may be.
Regards,
Nikita
Java's date/time maintainer has created a fork based on the original
Iana TZ data to put back some of the removed/deprecated data to
better serve their users, and I would think that this is also best
suited as a data set for PHP.If you want to read about the intricacies, see:
https://github.com/JodaOrg/global-tz#rationaleBut this does mean a divergence from the "official" TZ data,
although Joda's data is arguably better. My recommendation is that
from the 2022b release we switch to Joda's version. (I will today
merge in the 2022a data from the Iana source.)Keeping in mind that people deploying PHP on Linux usually end up
using OS-provided zoneinfo, do you know which source distros base that
on? I think we should follow the distro-consensus here, whatever that
may be.
NetBSD has switched, FreeBSD is entertaining the idea and offers the new
data as an option. I haven't seen any comments from Linux distributions.
Our long standing stance on distributions patching PHP for their own use
has always been "you're on your own". The data these users receive is
already degraded, due to their patching, and that Iana TZ has already
removed some historical data since a few releases. As this removal only
pertains pre-1970 data, where the Joda time version provides accurate
data for all countries (and not just aribitrary ones), I both don't see
that a divergence is a big problem, nor do I find it an argument for
releasing known-wrong data.
It is mostly African countries now with known-wrong data, but the TZ
maintainer tried merging Amsterdam and Brussels (removing likely-correct
pre-1970 Dutch data in favour of certainly-wrong pre-1970 Belgium data),
and several other European countries. That was stopped for now, but I am
certainly he'll try again.
I don't think it is acceptable for us to say that we're okay with some
countries data to be known-wrong.
cheers,
Derick
Hi!
...
In the last few years, the maintainer of the Iana TZ Data project has
diverged somewhat from the consensus of the community, and degraded some
data by no longer having an entry for each country and merged timezones
where data does not differ since 1970. (Removing transitions from these
regions where data does differ before 1970, even if these were
available).
...
Comments?
This article [1] mentions that tzdata can be built in a way to include
the "merged away" data:
It is possible to build tzdata with PACKRATDATA=backzone if
historic pre-1970 data is needed.
Would this be an option, too?
[1]
https://developers.redhat.com/articles/2022/01/28/tzdata-time-zone-database-rhel-2021-update
--
Regards,
Mike