On Thu, Apr 13, 2023 at 8:53 AM Herbert Groot Jebbink <herb...@groot.jebbink.nl> wrote: > > Op wo 12 apr. 2023 16:04 schreef Rowan Tommins <rowan.coll...@gmail.com>: > > > On Wed, 12 Apr 2023 at 13:25, Herbert Groot Jebbink < > > herb...@groot.jebbink.nl> wrote: > > > >> fallback for REQUEST_TIME and REQUEST_TIME_FLOAT to hrtime seems not > >> possible, hrtime is not based on the actual time, hrtime can be used to > >> calculate a duration or so, not to retrieve the actual time itself. > >> > > > > Fair enough, but that makes my first question all the more important: are > > there any situations or platforms where generating an hrtime value for > > every request would have a performance penalty? > > > > How does that performance (for everyone) compare with a single call to > > microtime(true) in your application to calculate the duration from > > REQUEST_TIME_FLOAT to start of profiling, with all subsequent profiling > > using hrtime? > > > > ok, valid point, I also found out that setting a REQUEST_TIME_x variable at > that point is too late, the request has been going on for a while, that's > most likely the reason it's coming from the active SAPI and not from the > current time. > > Thanks for the feedback, I will not file a RFC
If you're using php-fpm and nginx, you can set variables in NGINX (fastcgi.conf): fastcgi_param REQUEST_TIME $date_gmt; fastcgi_param REQUEST_TIME_ISO $time_iso8601; then it should be available in the $_SERVER object. I didn't test this, so it might need some experimentation to get it how you want it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
