Are you talking about general server benchmarks, HTTP server benchmarks or
PHP-only specific benchmarks (make test?)?
b.
On 19 October 2011 13:35, Lester Caine wrote:
> OK ... I've pulled out all the old benchmarking stuff, but being several
> years old, they seem to be a little 'light' in wh
On Wed, Oct 19, 2011 at 08:18:50AM +0100, Lester Caine wrote:
> I've come to one simple
> conclusion, and that is that the internal system always works with
> UTC times. All of the calculations and 'timing diagrams' therefore
> have unique and sequential times.
That is how PHP's DateTime works.
-
OK ... I've pulled out all the old benchmarking stuff, but being several years
old, they seem to be a little 'light' in what they are doing. I'm getting 34mS
test times on things that were probably a second or more when I first used them.
I've got two Linux machines running public accessible we
Hi,
2011/10/18 Stas Malyshev :
> Hi!
>
> Since we have next release planned on 20th, and since we have at least three
> unsolved issues for 5.4 yet which we expect resolution soon:
> - is_a question
> - serialization changes
> - date fixes
>
> I think the release on 20th should be beta2 and we can
On Tue, Oct 18, 2011 at 10:04 PM, Ferenc Kovacs wrote:
>> where is the question? You seem to be the only one to disagree with
>> the revert and the proposed patch. Rasmus and other agreed on it
>> already, here and the security list.
>
> please keep in mind that the security is a closed group so
Daniel Convissor wrote:
PHP's DateTime class has unexpected outcomes when dealing with the
transitions between Daylight Saving Time and Standard Time.
Properly defining, documenting and unit testing DateTime's behaviors is
important for PHP's future. This document seeks agreement on what the
exp
