In most instances integers and floats can be used interchangeably, which is why the patch was written in the way that it was. In the few rare cases (int) cast takes care of the trick, there is a substantial benefit for timings etc... to have higher precision timestamp available at no additional cost. Introducing additional server variables just makes things inconsistent, especially this late in the release cycle.
On Sat, Dec 24, 2011 at 10:07 AM, Pierre Joye <pierre....@gmail.com> wrote: > On Sat, Dec 24, 2011 at 3:47 PM, André Rømcke <a...@ez.no> wrote: > >> Yes, this is the one from Zeta Components MvcTools. >> In eZ Publish it was db based session gc using REQUEST_TIME >> and compatibility for potential extensions that might have used this >> variable via eZ Publish >> api: https://github.com/ezsystems/ezpublish/commit/3483c623769aa9ed3be7b6f33e3579cf8a8efd45 >> >> In both cases a (int) was added in front of the variable to make sure it >> still behaves the same, so not a big deal. >> But as also mentioned, changes like this requires patching to >> be compatible with 5.4. >> >> So unless this is done to be inline with some standard on such a server >> variable, I would suggest placing microtime on a separate server variable >> (since it is indeed useful to have it for time accumulators and performance >> metrics). > > > Right, and that's why I would be in favour of a BC change, maybe by > introducing a REQUEST_TIME_FLOAT instead, so people willing to use the > float version can still have it while the existing code needs no > change. > > Adding Ilia (who made that change) and the RMs to the list. > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
