FAQ
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!

Search Discussions

  • Pierre Joye at Dec 24, 2011 at 11:01 am
    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 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 Joye at Dec 24, 2011 at 11:04 am
    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 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 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
  • Derick Rethans at Dec 24, 2011 at 11:55 am

    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
  • André Rømcke at Dec 24, 2011 at 2:47 pm

    On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans 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).
  • Pierre Joye at Dec 24, 2011 at 3:07 pm

    On Sat, Dec 24, 2011 at 3:47 PM, André Rømcke 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,
  • Ilia Alshanetsky at Dec 24, 2011 at 3:18 pm
    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 wrote:
    On Sat, Dec 24, 2011 at 3:47 PM, André Rømcke 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 Joye at Dec 24, 2011 at 3:25 pm
    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 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 wrote:
    On Sat, Dec 24, 2011 at 3:47 PM, André Rømcke 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
  • Patrick ALLAERT at Dec 26, 2011 at 5:24 pm

    2011/12/24 Pierre Joye <pierre.php@gmail.com>:
    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 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, 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
  • Pierre Joye at Dec 27, 2011 at 3:19 am
    hi Patrick,
    On Mon, Dec 26, 2011 at 6:24 PM, Patrick ALLAERT 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,
  • Stas Malyshev at Dec 27, 2011 at 8:12 am
    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
  • Derick Rethans at Dec 27, 2011 at 10:37 am

    On Mon, 26 Dec 2011, Patrick ALLAERT wrote:

    2011/12/24 Pierre Joye <pierre.php@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 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
  • Pierre Joye at Dec 27, 2011 at 11:39 am
    hi Derick,
    On Tue, Dec 27, 2011 at 11:37 AM, Derick Rethans wrote:
    On Mon, 26 Dec 2011, Patrick ALLAERT wrote:

    2011/12/24 Pierre Joye <pierre.php@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 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,
  • Derick Rethans at Dec 27, 2011 at 12:19 pm

    On Tue, 27 Dec 2011, Pierre Joye wrote:
    On Tue, Dec 27, 2011 at 11:37 AM, Derick Rethans wrote:
    On Mon, 26 Dec 2011, Patrick ALLAERT wrote:

    2011/12/24 Pierre Joye <pierre.php@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 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
  • Pierre Joye at Dec 27, 2011 at 12:46 pm

    On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans 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,
  • Derick Rethans at Dec 27, 2011 at 12:52 pm

    On Tue, 27 Dec 2011, Pierre Joye wrote:
    On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans 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
  • Ilia Alshanetsky at Dec 27, 2011 at 2:55 pm
    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 wrote:
    On Tue, 27 Dec 2011, Pierre Joye wrote:
    On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans 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
  • Patrick ALLAERT at Dec 27, 2011 at 3:15 pm

    2011/12/27 Ilia Alshanetsky <ilia@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
  • Ilia Alshanetsky at Dec 27, 2011 at 4:43 pm
    The change is inside 5.4 version which adjust breaks BC.

    ---
    Ilia
    On Dec 27, 2011 10:15 AM, "Patrick ALLAERT" wrote:

    2011/12/27 Ilia Alshanetsky <ilia@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
  • Patrick ALLAERT at Dec 27, 2011 at 5:24 pm

    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?

    --
    Patrick
  • Ferenc Kovacs at Dec 27, 2011 at 8:01 pm

    On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT 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
    )

    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
  • André Rømcke at Jan 6, 2012 at 12:08 pm
    On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs wrote:
    On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT 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
  • Patrick ALLAERT at Jan 6, 2012 at 1:41 pm
    2012/1/6 André Rømcke <ar@ez.no>
    On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs wrote:


    On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT 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
    Fixed in master and PHP_5_4 as per discussed/suggested by introducing
    $_SERVER['REQUEST_TIME_FLOAT'].

    --
    Patrick
  • Lester Caine at Dec 27, 2011 at 3:32 pm

    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 Rethanswrote:
    On Tue, 27 Dec 2011, Pierre Joye wrote:

    On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethanswrote:
    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
  • Patrick ALLAERT at Dec 27, 2011 at 2:49 pm

    2011/12/27 Pierre Joye <pierre.php@gmail.com>:
    On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans 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)++
  • Damien Tournoud at Dec 27, 2011 at 6:37 pm

    On Sat, Dec 24, 2011 at 7:07 AM, Pierre Joye 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
  • Pierre Joye at Dec 24, 2011 at 3:00 pm

    On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans 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.

    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,
  • Nikita Popov at Dec 24, 2011 at 3:04 pm
    You missed the @ before the number ;)
    On Sat, Dec 24, 2011 at 4:00 PM, Pierre Joye wrote:
    On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans 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.

    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stefan Neufeind at Dec 24, 2011 at 11:07 am
    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 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!

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedDec 24, '11 at 10:13a
activeJan 6, '12 at 1:41p
posts29
users11
websitephp.net

People

Translate

site design / logo © 2018 Grokbase