Re: REQUEST_TIME change in PHP 5.4
| From: | André Rømcke | Date: | Fri, 06 Jan 2012 12:07:57 +0000 |
| Subject: | Re: REQUEST_TIME change in PHP 5.4 | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-57249@lists.php.net to get a copy of this message | ||
On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
>
> On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT <patrickallaert@php.net>wrote:
>
>> 2011/12/27 Ilia Alshanetsky <ilia@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