[php-maint] Bug#618462: Bug#618462: php5: Use of systems' embedded timezone data causes performance regression

[sean finney]

Hi Maciej,

Does this actually cause a quantifiable and significant performance
regression?  This possibility of performance issues was discussed some
time ago but it was decided that the stat calls would just hit the kernel
fs cache and not cause any serious problems.

If there are indeed problems, there are certainly ways this could be
worked around (building a binary cache kept up to date with the pkg
management system, for example), but it would add even further complexity
to the patch which we'd all prefer to avoid if possible.


To give you some extra background, since the PHP authors certainly have
their own take on the situation, but EVERY serious linux distribution
ships this patch in some form.  Redhat, Fedora, Debian, Ubuntu, SLES,
Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this patch.
So please keep that in mind when you here both sides of this argument :)


The problem is that when the OS distributors release a timezone update,
they don't want to *also* have to go package by package updating
indivudual and "customized" timezone databases that might be embedded
in a given application.  Neither do they want to continuously update the
version of PHP in their "stable" releases and have to deal with the numerous
regressions that would result.  The PHP tzdata changes are mixed in with the
mainline development, and sometimes depend on other changes within the
engine, so it's not really feasible to cherry pick out the changes into
a stable release, even if we wanted to.

This is a point of disagreement with the PHP authors, who want to have
control over this aspect of the engine themselves (and they certainly have
their justifications, such as systems with outdated or nonexistant tzdata,
plus they add some extra TZ annotations in their private copy).
Unfortunately they are interested in providing any other way to work
around this issue, despite the periodic overture from us or RedHat.
The invitation is still open to try and find a reasonable technical
solution for this, but I have been led to beleive that Derick has really
dug in his heels on the issue and it's not worth any of our time to
raise a big stink about it.



	sean