2012/1/6 André Rømcke
>
> 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 :
>>> > The change is inside 5.4 version which adjust breaks BC.
>>>
>>> I don't follow you here Ilia.
>>>
>
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 :
>> > 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/release
On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT wrote:
> 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 maj
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
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+
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 :
> > I think the REQUEST_TIME semantics of returning float should remain as
> is.
> >
> > -1 for adding further environment variables.
>
> As mentio
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
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?
Oppo
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 o
2011/12/27 Pierre Joye :
> 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_MSE
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) RE
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,
--
Pierre
@pierrej
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 :
> >> >
> >> > Right but there is a clear BC break here. And yes I really don't like
> >> > how datetime deals with th
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 :
>> >
>> > 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
On Mon, 26 Dec 2011, Patrick ALLAERT wrote:
> 2011/12/24 Pierre Joye :
> >
> > 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
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
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 bein
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 Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky wrote:
>> Introduc
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 u
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 cos
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/ezsys
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 fa
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[
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
>
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) c
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 an
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
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ømck
28 matches
Mail list logo
