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!
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,
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
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.
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,
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
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
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).
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/3483c623769aa9ed3be7b6f33e3579cf8a8efd45In 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
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.
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/3483c623769aa9ed3be7b6f33e3579cf8a8efd45In 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
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).
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.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/3483c623769aa9ed3be7b6f33e3579cf8a8efd45In 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
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).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
hi Patrick,
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
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
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).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
hi Derick,
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).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
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).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?
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
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
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
I think the REQUEST_TIME semantics of returning float should remain as is.
-1 for adding further environment variables.
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
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
The change is inside 5.4 version which adjust breaks BC.
Ilia
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
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
On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT patrickallaert@php.netwrote:
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
On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT patrickallaert@php.netwrote:
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
2012/1/6 André Rømcke ar@ez.no
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
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?
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
2011/12/27 Pierre Joye pierre.php@gmail.com:
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)++
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
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
You missed the @ before the number ;)
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 15.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 1and 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 1Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org