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
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
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
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
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
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)
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
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
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
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
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
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,
--
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
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
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
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
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.
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
(
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é
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
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
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
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
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
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
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:
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
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
28 matches
Mail list logo
