[tz] Using the tzdb: What's actually changed
derick at derickrethans.nl
Wed Sep 29 09:55:04 UTC 2021
On Tue, 28 Sep 2021, Anthony Hernandez via tz wrote:
> On Tue, Sep 28, 2021 at 8:43 AM Derick Rethans via tz <tz at 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
> 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
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.
More information about the tz