Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64160
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Date: Wed, 5 Dec 2012 09:54:30 -0600
Message-ID: <CACzKMq3hfNqS-jF+e1xivjFF+cFB+5p6DDJ4mFVRJkuwKmCFMQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: date/strtotime poor performance - further digging (v 5.4.9) [PATCH]
From: njaguar@gmail.com (Paul Taulborg)

I ended up digging deeper and created a patch for this, and have
created a bug with the patch attached.
https://bugs.php.net/bug.php?id=63699

Summary of changes:
- Created a new tz_checked_valid flag on the global date structure
- Created a callback method when date.timezone is modified by the ini (set)
- Callback checks validity if set during runtime, and will error (with
line number) accordingly. This is probably useful for some users that
might no otherwise have realized they made a mistake on their
ini_set() line in their code.
- In guess_timezone(), if tz_checked_valid is not set, attempts to
validate, errors if cannot.

As previously noted from my benchmarks, over 1 million runs, it
increased performance from:
date                    : 1.751 sec
strftime                : 1.872 sec
strtotime               : 3.195 sec

to:
date                    : 1.238 sec
strftime                : 0.999 sec
strtotime               : 2.337 sec

Here is a test case to show that it will not blow up on invalid
timezones, and revalidates accordingly:

<?php
ini_set('date.timezone', 'FAKE_TIMEZONE');
echo date('F j, Y, g:i a');

ini_set('date.timezone', 'America/Chicago');
echo date('F j, Y, g:i a');
?>

Note: If the ini is actually set wrong, it will not error until they
call a date function that makes use of the timezone, just like before.

Thanks!