[tz] Using the tzdb: What's actually changed

[Derick Rethans]

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 
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