|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #63957 REQUEST_TIME_FLOAT too high
Submitted: 2013-01-10 10:28 UTC Modified: 2013-01-14 01:40 UTC
Avg. Score:3.0 ± 1.6
Reproduced:1 of 2 (50.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: bugzilla77 at gmail dot com Assigned:
Status: Wont fix Package: *Web Server problem
PHP Version: 5.5.0alpha2 OS: win32, apache module
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
14 - 11 = ?
Subscribe to this entry?

 [2013-01-10 10:28 UTC] bugzilla77 at gmail dot com
is greater than

introduced in PHP 5.5 alpha (1-3)

Test script:

Expected result:
positive float (PHP 5.4 OK)

Actual result:
negative float


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-01-11 00:36 UTC]
microtime() and $_SERVER['REQUEST_TIME_FLOAT'] use different mechanisms to get the time: microtime() calls gettimeofday() internally, whereas $_SERVER['REQUEST_TIME_FLOAT'] uses whatever method the SAPI provides to get the request time (for instance, the apache2handler SAPI calls apr_time_as_msec()). In practice, there are likely to be slight variances between the two methods, since they do different things.

I don't see a sensible way we could change this without removing the semantics of $_SERVER['REQUEST_TIME_FLOAT'] actually being the server's request time (as opposed to just the startup time of PHP's request handling).

Marking won't fix.
 [2013-01-11 00:36 UTC]
-Status: Open +Status: Wont fix -Package: Date/time related +Package: *Web Server problem
 [2013-01-11 09:21 UTC] bugzilla77 at gmail dot com
Currently $_SERVER['REQUEST_TIME_FLOAT'] is useless in determining the time of 
generating web pages.

I think that PHP should setting $_SERVER['REQUEST_TIME_FLOAT'] = microtime(true)
on PHP's request handling.
 [2013-01-11 09:23 UTC] bugzilla77 at gmail dot com
Why this problem is not found in PHP 5.4?
 [2013-01-14 01:40 UTC]
I can't reproduce this very reliably on either branch, so I don't think it's version specific as such.

Changing $_SERVER['REQUEST_TIME_FLOAT'] to be microtime(true) on startup misses the point of what the server variable represents: it's what the Web server believes the request time to be, not when the PHP interpreter was invoked.

If you want microtime(true), then set a variable to that at the top of your script.
 [2013-01-19 19:34 UTC] bugzilla77 at gmail dot com
Maybe PHP should set the $_SERVER['REQUEST_TIME_FLOAT'] value


MIN of apr_time_as_msec() , microtime(true) ???????
 [2013-01-19 19:39 UTC] bugzilla77 at gmail dot com
Test script (fixed):

but problem still the same
 [2013-01-25 11:09 UTC] lunter2 at gmail dot com
I can confirm this problem introduced in PHP 5.5


Max difference observed from is -1200ms !
 [2013-01-25 11:21 UTC] lunter2 at gmail dot com
This very big problem is introduced in php 5.5.
PHP 5.4 never returns negative value.
 [2013-01-27 18:16 UTC] adam123 at hotmail dot com
The difference increases in time to run the server.
I am now watching -5.5 seconds.
 [2013-01-27 18:20 UTC] adam123 at hotmail dot com
The difference increases in time to run the server (few days).
I am now watching -5.5 seconds.
After Apache restar difference -20ms.
 [2013-01-27 18:59 UTC] bugzilla77 at gmail dot com
Sorry - this not a bug with $_SERVER['REQUEST_TIME_FLOAT']

This is problem with microtime(true).


I will report a new bug.
 [2013-01-27 19:09 UTC] bugzilla77 at gmail dot com

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 14 17:01:28 2024 UTC