# REQUEST_TIME change in PHP 5.4 - Thread: https://externals.io/message/57070 - Original archive: https://news-web.php.net/php.internals/57070 - Started by ar@ez.no on 2011-12-24T10:13:27+00:00 - Messages: 28 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/57070.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #57070 — ar@ez.no — 2011-12-24T10:13:27+00:00 URL: https://externals.io/message/57070#57070 Hi, a bit late to the party maybe, but why was REQUEST_TIME broken in 5.4 instead of adding a new parameter? (like REQUEST_MICROTIME) Is the Release Process not followed yet? - x.y.z to x.y+1.z - (...) - Backward compatibility must be kept ( https://wiki.php.net/rfc/releaseprocess ) It is not a big deal (we are used to it), but it does break a couple of things in for instance eZ Publish & Zeta Components which will by the nature of things not be fixed before the next release. Most customers will hopefully make sure the version of the software they are using is tested/certified for php 5.4 before upgrading, but from experience, some will not. Other then that, happy xmas! --- ## #57071 — Pierre Joye — 2011-12-24T11:01:41+00:00 URL: https://externals.io/message/57070#57071 · In reply to: #57070 hi, I don't remember a change about it and did not check the log yet. Would you mind to write here how it is broken please? It could help the discussions :) But yes, if it has changed in an incompatible way, I'd to go with a revert as well. Cheers, > Hi, > > > > a bit late to the party maybe, but why was REQUEST_TIME broken in 5.4 > instead of adding a new parameter? (like REQUEST_MICROTIME) > Is the Release Process not followed yet? > > >   - x.y.z to x.y+1.z >      - (...) >      - Backward compatibility must be kept > > ( https://wiki.php.net/rfc/releaseprocess ) > > > It is not a big deal (we are used to it), but it does break a couple of > things in for instance eZ Publish & Zeta Components which will by the > nature of things not be fixed before the next release. > Most customers will hopefully make sure the version of the software they > are using is tested/certified for php 5.4 before upgrading, but from > experience, some will not. > > > Other then that, happy xmas! -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57072 — Pierre Joye — 2011-12-24T11:04:39+00:00 URL: https://externals.io/message/57070#57072 · In reply to: #57071 hm, I should read better... "The REQUEST_TIME value inside server now returns a floating point number" How does it break BC except if one is doing a strong type test? which makes very little sense in this case. While a fix is easy, (int) casting and works with all previous versions, I would like to know how it breaks apps out there. > hi, > >  I don't remember a change about it and did not check the log yet. > Would you mind to write here how it is broken please? It could help > the discussions :) > > But yes, if it has changed in an incompatible way, I'd to go with a > revert as well. > > Cheers, > > > > […] > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57077 — Derick Rethans — 2011-12-24T11:55:19+00:00 URL: https://externals.io/message/57070#57077 · In reply to: #57072 > hm, I should read better... > > "The REQUEST_TIME value inside server now returns a floating point number" > > How does it break BC except if one is doing a strong type test? which > makes very little sense in this case. > > While a fix is easy, (int) casting and works with all previous > versions, I would like to know how it breaks apps out there. new DateTime("@{$_SERVER['REQUEST_TIME']}"); f.e. regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #57084 — ar@ez.no — 2011-12-24T14:47:18+00:00 URL: https://externals.io/message/57070#57084 · In reply to: #57077 > > > > […] > number" > > […] > > new DateTime("@{$_SERVER['REQUEST_TIME']}"); f.e. > > 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). --- ## #57086 — Pierre Joye — 2011-12-24T15:00:09+00:00 URL: https://externals.io/message/57070#57086 · In reply to: #57077 > new DateTime("@{$_SERVER['REQUEST_TIME']}"); f.e. Not following you here, how does it work better in 5.3.x? It is a float but datetime fails just like before. php536nts>php -n -r "var_dump($_SERVER['REQUEST_TIME']);new Datetime($_SERVER['REQUEST_TIME']);" int(1324738540) Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct(): Failed to parse time string (1324738540) at position 8 (4): Unexpected character' in Command line code:1 Stack trace: #0 Command line code(1): DateTime->__construct('1324738540') #1 {main} thrown in Command line code on line 1 5.3.9rc4>php -n -r "var_dump($_SERVER['REQUEST_TIME']);new Datetime($_SERVER['REQUEST_TIME']);" int(1324738655) Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct(): Failed to parse time string (1324738655) at position 8 (5): Unexpected character' in Command line code:1 Stack trace: #0 Command line code(1): DateTime->__construct('1324738655') #1 {main} thrown in Command line code on line 1 and with 5.4.0RC4: 5.4.0rc4-nts>php -n -r "var_dump($_SERVER['REQUEST_TIME']);new Datetime($_SERVER['REQUEST_TIME']);" float(1324738763.2993) Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct(): Failed to parse time string (1324738763.2993) at position 8 (6): Unexpected character' in Command line code:1 Stack trace: #0 Command line code(1): DateTime->__construct('1324738763.2993') #1 {main} thrown in Command line code on line 1 Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57087 — Nikita Popov — 2011-12-24T15:04:19+00:00 URL: https://externals.io/message/57070#57087 · In reply to: #57086 You missed the @ before the number ;) > > > > […] > > Not following you here, how does it work better in 5.3.x? It is a > float but datetime fails just like before. > > php536nts>php -n -r "var_dump($_SERVER['REQUEST_TIME']);new > Datetime($_SERVER['REQUEST_TIME']);" > int(1324738540) > > Fatal error: Uncaught exception 'Exception' with message > 'DateTime::__construct(): Failed to parse time string (1324738540) at > position 8 (4): Unexpected character' in Command line code:1 > Stack trace: > #0 Command line code(1): DateTime->__construct('1324738540') > #1 {main} >  thrown in Command line code on line 1 > > > 5.3.9rc4>php -n -r "var_dump($_SERVER['REQUEST_TIME']);new > Datetime($_SERVER['REQUEST_TIME']);" > int(1324738655) > > Fatal error: Uncaught exception 'Exception' with message > 'DateTime::__construct(): Failed to parse time string (1324738655) at > position 8 (5): Unexpected character' in Command line code:1 > Stack trace: > #0 Command line code(1): DateTime->__construct('1324738655') > #1 {main} >  thrown in Command line code on line 1 > > and with 5.4.0RC4: > > 5.4.0rc4-nts>php -n -r "var_dump($_SERVER['REQUEST_TIME']);new > Datetime($_SERVER['REQUEST_TIME']);" > float(1324738763.2993) > > Fatal error: Uncaught exception 'Exception' with message > 'DateTime::__construct(): Failed to parse time string > (1324738763.2993) at position 8 (6): Unexpected character' in Command > line code:1 > Stack trace: > #0 Command line code(1): DateTime->__construct('1324738763.2993') > #1 {main} >  thrown in Command line code on line 1 > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57088 — Pierre Joye — 2011-12-24T15:07:09+00:00 URL: https://externals.io/message/57070#57088 · In reply to: #57084 > 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 --- ## #57089 — Ilia Alshanetsky — 2011-12-24T15:18:08+00:00 URL: https://externals.io/message/57070#57089 · In reply to: #57088 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. > > > > […] > > > 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 --- ## #57090 — Pierre Joye — 2011-12-24T15:25:12+00:00 URL: https://externals.io/message/57070#57090 · In reply to: #57089 hi Ilia, Right but there is a clear BC break here. And yes I really don't like how datetime deals with that but it is how it is, and it is certainly the only case where it fails (or almost). > 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. > > > > […] -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57104 — Patrick ALLAERT — 2011-12-26T17:24:26+00:00 URL: https://externals.io/message/57070#57104 · In reply to: #57090 2011/12/24 Pierre Joye : > hi Ilia, > > Right but there is a clear BC break here. And yes I really don't like > how datetime deals with that but it is how it is, and it is certainly > the only case where it fails (or almost). > > > > […] On one side there's a clear BC break which, according to the related RFC, is to be considered as a blocker, on the other one, a strong and valid argument regarding spreading additional server variables. I'm not sure being late in the release process is truely a valid argument for accepting a BC break. Can't we make some compromise here like making all date/time classes/functions work uniformly with ints and floats? Working with date/time features based on $_SERVER['REQUEST_TIME'] is certainly not something fancy! Patrick --- ## #57106 — Pierre Joye — 2011-12-27T03:19:09+00:00 URL: https://externals.io/message/57070#57106 · In reply to: #57104 hi Patrick, > On one side there's a clear BC break which, according to the related > RFC, is to be considered as a blocker, on the other one, a strong and > valid argument regarding spreading additional server variables. > I'm not sure being late in the release process is truely a valid > argument for accepting a BC break. > Can't we make some compromise here like making all date/time > classes/functions work uniformly with ints and floats? > Working with date/time features based on $_SERVER['REQUEST_TIME'] is > certainly not something fancy! I tend to agree with you here, making date works smoothly with both would be the best way. However it requires more changes and work (and more risks) that simply add a new server variable. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57107 — Stas Malyshev — 2011-12-27T08:12:16+00:00 URL: https://externals.io/message/57070#57107 · In reply to: #57104 Hi! > On one side there's a clear BC break which, according to the related > RFC, is to be considered as a blocker, on the other one, a strong and > valid argument regarding spreading additional server variables. > I'm not sure being late in the release process is truely a valid > argument for accepting a BC break. If we are to fix it, I don't think it's too late. One of the purposes of the RC process is to find out stuff like this - i.e. BC breaks - and fix them before the release. I do not see a big risk in adding new SERVER variable - I don't believe there's any code that relies on certain variable *not* existing, and since the code to produce it already exists and considered stable, there's very little risk in just renaming it. > Can't we make some compromise here like making all date/time > classes/functions work uniformly with ints and floats? However for this is probably way too late, since it's not a BC fix, it's completely new and untested functionality. So if somebody wants to make a patch that makes REQUEST_TIME be back as it was and make REQUEST_TIME_MSEC (or something like this) have msec precision - I think it would be fine. Doing anything to "all date/time classes/functions" is definitely out of the question, IMO. For 5.4.1, it may be considered if done in a clean manner, but not for 5.4.0. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #57110 — Derick Rethans — 2011-12-27T10:37:37+00:00 URL: https://externals.io/message/57070#57110 · In reply to: #57104 > 2011/12/24 Pierre Joye : > > […] > > On one side there's a clear BC break which, according to the related > RFC, is to be considered as a blocker, An RFC? Which one? > on the other one, a strong and > valid argument regarding spreading additional server variables. > I'm not sure being late in the release process is truely a valid > argument for accepting a BC break. > Can't we make some compromise here like making all date/time > classes/functions work uniformly with ints and floats? It's parsing a *string*, not an int or float. Changing anything with how the parser works is definitely going to be a clear BC break. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #57111 — Pierre Joye — 2011-12-27T11:39:17+00:00 URL: https://externals.io/message/57070#57111 · In reply to: #57110 hi Derick, > > > > […] > > An RFC? Which one? https://wiki.php.net/rfc/releaseprocess Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57112 — Derick Rethans — 2011-12-27T12:19:40+00:00 URL: https://externals.io/message/57070#57112 · In reply to: #57111 > > > […] > > https://wiki.php.net/rfc/releaseprocess Ah, that one. I got lost between all the commas and thought he meant an RFC for changing REQUEST_TIME from int to float :-) Derick --- ## #57114 — Pierre Joye — 2011-12-27T12:46:23+00:00 URL: https://externals.io/message/57070#57114 · In reply to: #57112 > Ah, that one. I got lost between all the commas and thought he meant an > RFC for changing REQUEST_TIME from int to float :-) :) Which name should we use? a) REQUEST_TIME_FLOAT b) REQUEST_TIME_MSEC c) other? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57115 — Derick Rethans — 2011-12-27T12:52:04+00:00 URL: https://externals.io/message/57070#57115 · In reply to: #57114 > > > > […] > > Which name should we use? > > a) REQUEST_TIME_FLOAT > b) REQUEST_TIME_MSEC > c) other? I'd vote for a (REQUEST_TIME_FLOAT), as MSEC is not what it really does. Depending on the time and precision it might not show miliseconds f.e. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #57120 — Patrick ALLAERT — 2011-12-27T14:49:15+00:00 URL: https://externals.io/message/57070#57120 · In reply to: #57114 2011/12/27 Pierre Joye : > > > > […] > > :) > > Which name should we use? > > a) REQUEST_TIME_FLOAT > b) REQUEST_TIME_MSEC > c) other? a)++ --- ## #57122 — Ilia Alshanetsky — 2011-12-27T14:55:49+00:00 URL: https://externals.io/message/57070#57122 · In reply to: #57115 I think the REQUEST_TIME semantics of returning float should remain as is. -1 for adding further environment variables. > > > > […] > > I'd vote for a (REQUEST_TIME_FLOAT), as MSEC is not what it really does. > Depending on the time and precision it might not show miliseconds f.e. > > cheers, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug --- ## #57123 — Patrick ALLAERT — 2011-12-27T15:15:35+00:00 URL: https://externals.io/message/57070#57123 · In reply to: #57122 2011/12/27 Ilia Alshanetsky : > I think the REQUEST_TIME semantics of returning float should remain as is. > > -1 for adding further environment variables. As mentioned earlier, I don't like this option very much but at least it solves the BC problem. Do you have any other proposal to share? Opposing to that without proposing a solution kinda looks like "I don't bother if it breaks BC". -- Patrick --- ## #57124 — Lester Caine — 2011-12-27T15:32:17+00:00 URL: https://externals.io/message/57070#57124 · In reply to: #57122 Ilia Alshanetsky wrote: > I think the REQUEST_TIME semantics of returning float should remain as is. > > -1 for adding further environment variables. A proper explanation of why you take that attitude would be helpful. Personally I expect REQUEST_TIME to be in the same resolution as the http format time stamps which does not include milliseconds (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1). Personally DATE is a floating point value with the fractional part being the fraction of the day. So adding another variation to cope with does not make any sense. So adding a non-standard environment variable for those who want it rather than screwing up the existing one is the logical approach? > > > […] -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #57132 — Ilia Alshanetsky — 2011-12-27T16:43:29+00:00 URL: https://externals.io/message/57070#57132 · In reply to: #57123 The change is inside 5.4 version which adjust breaks BC. --- Ilia > 2011/12/27 Ilia Alshanetsky : > > […] > is. > > […] > > As mentioned earlier, I don't like this option very much but at least > it solves the BC problem. > Do you have any other proposal to share? > > Opposing to that without proposing a solution kinda looks like "I > don't bother if it breaks BC". > > -- > Patrick --- ## #57133 — Patrick ALLAERT — 2011-12-27T17:24:01+00:00 URL: https://externals.io/message/57070#57133 · In reply to: #57132 2011/12/27 Ilia Alshanetsky : > The change is inside 5.4 version which adjust breaks BC. I don't follow you here Ilia. As per https://wiki.php.net/rfc/releaseprocess: * "Backward compatibility must be respected with the same major releases, for example from 5.2 to 5.6." * Going from x.y.z to x.y+1.z, it is ok to break *binary* compatibility but "Backward compatibility must be kept". However: new DateTime("@{$_SERVER['REQUEST_TIME']}"); works in 5.3 but not in 5.4. AFAIK, creating a DateTime object based on the REQUEST_TIME is not an exotic thing. For sure, the fix is easy, but that is not the point, it *will* actually break applications. Did I miss something? -- Patrick --- ## #57135 — Damien Tournoud — 2011-12-27T18:37:28+00:00 URL: https://externals.io/message/57070#57135 · In reply to: #57088 > 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. We spotted the same exact thing when doing the first tests of Drupal on PHP 5.4, which lead to the following change (already released in all the affected versions of Drupal): http://drupal.org/node/1209470 Given how most of PHP miserably fails to handle float timestamp, I'm in favor of reverting the change too. Damien --- Next page: https://externals.io/message/57070.md?page=2