Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT
patrickalla...@php.netwrote:
2011/12/27 Ilia Alshanetsky i...@ilia.ws:
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?
I think that he is referring to that we already break BC with 5.4
(removing magic_quotes, register_globals, break/continue
$var, allow_call_time_pass_reference, some deprecated session_ functions,
safe_mode, etc. for a complete list see
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/UPGRADING?view=markup
)
These are mostly removal of features, and most of these have been
deprecated for quite a while.
The REQUEST_TIME change however is a change of behaviour that has not been
warned about up front, which imo is a worse BC break then most of the rest.
And arguing for ignoring one bc break/bug/mistake because there are others
is.. well.. :)
However I tend to agree with you, that this BC break isn't really worth
it, we can see that there are common apps stumbling across this change, and
albeit the new behavior can be useful for many people, they wouldn't really
mind if we add this as a new variable imo.
Great, so I do think most people agree that this can, and should be fixed
before 5.4 by instead expose microtime on a separate variable called
REQUEST_TIME_FLOAT.
+1
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
2012/1/6 André Rømcke a...@ez.no
On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT patrickalla...@php.net
wrote:
2011/12/27 Ilia Alshanetsky i...@ilia.ws:
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?
I think that he is referring to that we already break BC with 5.4 (removing
magic_quotes, register_globals, break/continue
$var, allow_call_time_pass_reference, some deprecated session_ functions,
safe_mode, etc. for a complete list
see http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/UPGRADING?view=markup )
These are mostly removal of features, and most of these have been deprecated
for quite a while.
The REQUEST_TIME change however is a change of behaviour that has not been
warned about up front, which imo is a worse BC break then most of the rest.
And arguing for ignoring one bc break/bug/mistake because there are others
is.. well.. :)
However I tend to agree with you, that this BC break isn't really worth it,
we can see that there are common apps stumbling across this change, and
albeit the new behavior can be useful for many people, they wouldn't really
mind if we add this as a new variable imo.
Great, so I do think most people agree that this can, and should be fixed
before 5.4 by instead expose microtime on a separate variable
called REQUEST_TIME_FLOAT.
+1
Fixed in master and PHP_5_4 as per discussed/suggested by introducing
$_SERVER['REQUEST_TIME_FLOAT'].
--
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Mon, 26 Dec 2011, Patrick ALLAERT wrote: 2011/12/24 Pierre Joye pierre@gmail.com: 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 Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky i...@ilia.ws wrote: Introducing additional server variables just makes things inconsistent, especially this late in the release cycle. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
2011/12/27 Ilia Alshanetsky i...@ilia.ws: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
2011/12/27 Pierre Joye pierre@gmail.com: On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans der...@php.net wrote: 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? a)++ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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? On Tue, Dec 27, 2011 at 7:52 AM, Derick Rethansder...@php.net wrote: On Tue, 27 Dec 2011, Pierre Joye wrote: On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethansder...@php.net wrote: 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? 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. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
The change is inside 5.4 version which adjust breaks BC. --- Ilia On Dec 27, 2011 10:15 AM, Patrick ALLAERT patrickalla...@php.net wrote: 2011/12/27 Ilia Alshanetsky i...@ilia.ws: 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
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Tue, 27 Dec 2011, Pierre Joye wrote: On Tue, Dec 27, 2011 at 11:37 AM, Derick Rethans der...@php.net wrote: On Mon, 26 Dec 2011, Patrick ALLAERT wrote: 2011/12/24 Pierre Joye pierre@gmail.com: 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 Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky i...@ilia.ws wrote: Introducing additional server variables just makes things inconsistent, especially this late in the release cycle. 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
I think the REQUEST_TIME semantics of returning float should remain as is. -1 for adding further environment variables. On Tue, Dec 27, 2011 at 7:52 AM, Derick Rethans der...@php.net wrote: On Tue, 27 Dec 2011, Pierre Joye wrote: On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans der...@php.net wrote: 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Tue, 27 Dec 2011, Pierre Joye wrote: On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans der...@php.net wrote: 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans der...@php.net wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
hi Derick, On Tue, Dec 27, 2011 at 11:37 AM, Derick Rethans der...@php.net wrote: On Mon, 26 Dec 2011, Patrick ALLAERT wrote: 2011/12/24 Pierre Joye pierre@gmail.com: 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 Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky i...@ilia.ws wrote: Introducing additional server variables just makes things inconsistent, especially this late in the release cycle. 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? https://wiki.php.net/rfc/releaseprocess 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
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
2011/12/27 Ilia Alshanetsky i...@ilia.ws:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Sat, Dec 24, 2011 at 7:07 AM, Pierre Joye pierre@gmail.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT patrickalla...@php.netwrote:
2011/12/27 Ilia Alshanetsky i...@ilia.ws:
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?
I think that he is referring to that we already break BC with 5.4 (removing
magic_quotes, register_globals, break/continue
$var, allow_call_time_pass_reference, some deprecated session_ functions,
safe_mode, etc. for a complete list see
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/UPGRADING?view=markup
)
However I tend to agree with you, that this BC break isn't really worth it,
we can see that there are common apps stumbling across this change, and
albeit the new behavior can be useful for many people, they wouldn't really
mind if we add this as a new variable imo.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
hi Patrick, On Mon, Dec 26, 2011 at 6:24 PM, Patrick ALLAERT patrickalla...@php.net wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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, On Sat, Dec 24, 2011 at 11:13 AM, André Rømcke a...@ez.no wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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. On Sat, Dec 24, 2011 at 12:01 PM, Pierre Joye pierre@gmail.com wrote: 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, On Sat, Dec 24, 2011 at 11:13 AM, André Rømcke a...@ez.no wrote: 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 -- 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
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
Haven't tried myself yet but could it be André is refering to a change from Ilia from 11/2010? http://git.php.net/?p=php-src.git;a=commit;h=435783f703bc762aad0f9269234bd383d4a55230 Kind regards, Stefan On 12/24/2011 12:01 PM, Pierre Joye wrote: 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, On Sat, Dec 24, 2011 at 11:13 AM, André Rømcke a...@ez.no wrote: 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! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Sat, 24 Dec 2011, Pierre Joye wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans der...@php.net wrote:
On Sat, 24 Dec 2011, Pierre Joye wrote:
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.
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).
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans der...@php.net wrote:
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.
php536ntsphp -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.9rc4php -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-ntsphp -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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
You missed the @ before the number ;)
On Sat, Dec 24, 2011 at 4:00 PM, Pierre Joye pierre@gmail.com wrote:
On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans der...@php.net wrote:
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.
php536ntsphp -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.9rc4php -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-ntsphp -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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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 Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky i...@ilia.ws wrote: 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 -- 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
