On Fri, Sep 20, 2013 at 10:01 AM, ruben wrote:
> Pascal Chevrel wrote:
>
>> Le 20/09/2013 14:06, ruben a écrit :
>>
>>> Hi,
>>>
>>> first of all I want to say that I am just a newbie in PHP. I am
>>> switching to PHP from other languages and I am exploring how PHP manages
>>> references. To do th
On Wed, Sep 11, 2013 at 10:47 AM, Lester Caine wrote:
> Paul Taulborg wrote:
>
>> Don't make this more complicated than it needs to be, observe:
>> http://news.php.net/php.internals
>>
>> 1) We already have a basic/simple web interface.
>> 2) This could
Don't make this more complicated than it needs to be, observe:
http://news.php.net/php.internals
1) We already have a basic/simple web interface.
2) This could be extended to have the features of forum software
(threading, sorting, searching, voting, filtering)
3) All email posts would go to the e
On Wed, Feb 20, 2013 at 1:54 PM, David Soria Parra wrote:
> On 2013-02-19, Stas Malyshev wrote:
>> Hi!
>>
>>> echo date_create('@1361240634')->format('Y-m-d');
>>> // output: 2013-02-19
>>>
>>> echo date('Y-m-d',1361240634);
>>> // output: 2013-02-18
>>
>> timestamp dates are created with UTC TZ,
https://bugs.php.net/bug.php?id=63941
Per discussion with Nuno Lopes and Christopher Jones, I have created
another patch to simplify guess_timezone() in ext/date/php_date.c
Internals summary: removes the newly patched in int value that caches
whether a timezone was previously checked or not, as w
I submitted a bugfix patch for this one:
https://bugs.php.net/bug.php?id=63615 on 2012-12-06
and asked for feedback here, to make sure this was intended
functionality. I also have not heard back, and the bug is still
unassigned. It's not something that ever affected me personally, it
was a random b
Are there any updates on this? I submitted this patch a month ago that
is a significant performance increase for some commonly used date/time
functions:
https://bugs.php.net/bug.php?id=63699
Can anyone provide feedback on this, and any possible reasons why this
seems to be shelved?
Thanks!
--
P
Sorry for the double message, still getting used to doing patches
instead of applying changes directly. I accidentally attached an old
patch file, not the latest. The previous had a bug in
php_date_initialize() which I caught in my testing (I left the local
variable tzi, by mistake, instead of usin
Went through and did some general code cleanup, namely removing
tabs/spaces from empty lines, or trailing spaces/tabs.
The exceptions to that are:
php_date_initialize() -- reorganized timezone setting to do it all at
once without the need for temporary variables. This should be slightly
faster, an
Okay, here is the proper fixed patch, tested via various methods:
$d1 = new DateTime;
while(1) {
// no memory leak
$d1->modify("Tue, 10 Apr 2012 11:27:56 +0300");
// memory leak - now fixed with new patch
$d1->modify("Tue, 10 Apr 2012 11:27:56 CST");
// no memory leak
$d1->modi
Can someone remove the patch from this bug for me? While it fixes the
problem, it opens up some potential memory leaks, so I'd hate to see
it get implemented by mistake before I get a chance to fix that as
well.
Thanks!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visi
I looked into this, and the modify function was not setting the
timezone information back to the parent dateobj. I have created a
patch that does this, IF the timezone information is set on the new
modified timestamp. It is attached to the bug itself, and here as
well.
This is, of course, assuming
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
So, I've been going through the internals of date() and related,
trying to isolate where some poor performance is, to try and find ways
to optimize it. In doing so, I came across this:
On line 863 of ext/date/php_date.c is this code:
} else if (*DATEG(default_timezone) &&
timelib_timezone_
:
>
>
> On 12/01/2012 10:21 AM, Paul Taulborg wrote:
>>
>>
>> [php_date.c patch]
>
>
> Thanks for the patch. To ensure it isn't lost, can you open a bug at
> https://bugs.php.net/ and attach it? And/or submit a pull request at
> https:
--- php-5.4.9_orig/ext/date/php_date.c 2012-11-20 23:12:20.0 -0600
+++ php-5.4.9/ext/date/php_date.c 2012-12-01 05:38:22.136264276 -0600
@@ -948,6 +948,7 @@
timelib_time_offset *offset = NULL;
timelib_sll isoweek, isoyear;
int rfc_co
My apologies, pasting the patch in directly:
--- php-5.4.9_orig/ext/date/php_date.c 2012-11-20 23:12:20.0 -0600
+++ php-5.4.9/ext/date/php_date.c 2012-12-01 05:38:22.136264276 -0600
@@ -948,6 +948,7 @@
timelib_time_offset *offset = NULL;
timelib_sll isoweek,
I am migrating from 4.4.9 to some new servers I built out, and wrote a
benchmark suite that is testing many individual aspects of PHP so I
could see what sort of performance benefits I might see not only from
the new server, but moving off my custom forked 4.4.9 branch. Here's a
snippet of some of
18 matches
Mail list logo
