Edit report at http://bugs.php.net/bug.php?id=54250&edit=1
ID: 54250
Comment by: maciej at wiercinski dot net
Reported by: maciej at wiercinski dot net
Summary: date_default_timezone_set stat()'s whole
/usr/share/zoneinfo upon first call
Status: Bogus
Type: Bug
Package: Date/time related
Operating System: Linux 2.6
PHP Version: 5.3.5
Block user comment: N
Private report: N
New Comment:
johan...@php.net:
I can see at least two problems Debian (and other distribution)
maintainers will
have with the solution you have proposed. They would have to make PHP
dependent
on PECL, which is currently not the case (at least not in Debian). On
other hand
it will eventually lead to a situation in which PHP's timezone update
has been
rolled out and system's not, or vice-versa.
Previous Comments:
------------------------------------------------------------------------
[2011-03-16 18:56:32] johan...@php.net
vJust a small comment on
> 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 not true. Distributions can distribute the timezone update using
the pecl/timzeone package. No messing with engine stuff needed.
------------------------------------------------------------------------
[2011-03-15 18:52:29] seanius at debian dot org
Hi guys,
We'll take up further discussion on the bug over there, but thought I
would cut/paste the (slightly amended) initial response here just for
posterity's sake.
===
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, 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: 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
individual 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 not 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.
------------------------------------------------------------------------
[2011-03-15 13:01:55] maciej at wiercinski dot net
Thanks for the update, it's indeed Debian's fault.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618462
------------------------------------------------------------------------
[2011-03-14 19:36:38] der...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Complain at your distribution for messing it up.
------------------------------------------------------------------------
[2011-03-14 19:27:58] ras...@php.net
I think this is going to make Derick's head explode :)
This is likely due to the fact that Ubuntu patches PHP to use the system
timezone
info as opposed to the default bundled data. If you build a clean
version of PHP
on Ubuntu using the code we actually distribute, I think you will find
that the
problem goes away.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=54250
--
Edit this bug report at http://bugs.php.net/bug.php?id=54250&edit=1
