On Tue, 28 Sep 2021, Anthony Hernandez via tz wrote:
On Tue, Sep 28, 2021 at 8:43 AM Derick Rethans via tz <tz@iana.org> wrote:
On Tue, 28 Sep 2021, Watson Ladd via tz wrote:
I see a lot of complaints, and very few details about the applications affected. Which makes me skeptical they actually exist.
PHP has millions of users, can you guarantee that it won't be a problem for any of them?
Sorry but how is that a problem for tzdb?
It will become a problem when I mention to PHP users that PHP's policy has always been "we bundle what tzdata does, if you have problems with the data, complain there", which likely created more Kiev/Kyiv discussions that I would have liked to see.
It's pretty well established that the primary focus of the database has to do with maintaining the integrity of data post-1970.
It's pretty well established for people on this list. I don't have the problem with *focussing* on post-1970 data. I have a problem with people using pre-1970 data succesfully, with likely accurate data, that are then forced to use pre-1970 that is demonstratively wrong.
If any downstream application or language is impacted by an action taken in the spirit of that, it's not tzdb's problem.
When the requirement arises for pre-1970s timezone data, the backzone files do exist and there have been multiple strategies discussed at this point on how to use the ones that might be needed.
PHP's users do not have the choice which data to pick. It is either what I bundle through timelib, or what Linux distrbutions bundle as OS zoneinfo files. They can't make the choice of whether to use backzone, packrat, or any other fork of the data. Nor would they even have the slightest idea that these things even exist. By replacing known-mostly-good data with known-wrong data you pretty much sabotage their use cases. cheers, Derick