[PHP-BUG] Req #64313 [NEW]: DateTime DateTimeZone constructs should emit DateTimeException
From: mattsch at gmail dot com
Operating system:
PHP version: 5.3.22
Package: Date/time related
Bug Type: Feature/Change Request
Bug description:DateTime DateTimeZone constructs should emit DateTimeException
Description:
DateTime and DateTimeZone constructs currently emit Exception but they
should really emit an exception related to their respective classes. The
reason for this is the code can run in multiple environments (ui, phpunit,
etc). If I want the exception to bubble up to the base exception in my
application environment, I want to catch it and rethrow it with an
exception that ultimately extends my app base exception. As a result, I
must catch the base php Exception class and rethrow it with the wrapper
exception which extends my base app exception. The problem comes when I
try to run testcases on the class in the phpunit environment. Since
phpunit emits exceptions, catching Exception will also catch phpunit
environment exceptions which is not what I want. As a result, I must check
the instance of the exception and allow phpunit exceptions to go through
unchanged. If the DateTime and DateTimeZone classes did not throw
Exception, then this would not be a problem. In fact, I don't think any
php command should actually throw the main php Exception and should always
throw an exception that is extended from Exception to avoid problems like
this.
Test script:
---
?php
class DateTimeWrapper
{
private $dateTime;
public function __construct($time = 'now', DateTimeZone $timezone =
null,
$format = null)
{
$this-setDateTime($time, $timezone, $format);
}
public function setDateTime($time = 'now', DateTimeZone $timezone =
null,
$format = null)
{
try {
$this-dateTime = new DateTime($time, $timezone);
}
catch (Exception $e) {
/*
PHP DateTime really shouldn't throw the catch
all Exception so the
workaround is
to keep this from catching phpunit exceptions
as well so do instance
checks on it.
*/
// @codeCoverageIgnoreStart
if ($e instanceof PHPUnit_Framework_Error
|| $e instanceof PHPUnit_Framework_Exception) {
throw $e;
}
// @codeCoverageIgnoreEnd
throw new DateTimeWrapperException($e-getMessage(),
$e-getCode(),
$e);
}
}
}
Expected result:
php should not throw Exception directly but rather an exception that
extends Exception.
Actual result:
--
php throws Exception in places like DateTime and DateTimeZone when it
should really throw an exception like DateTimeException instead which would
extend Exception.
--
Edit bug report at https://bugs.php.net/bug.php?id=64313edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64313r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64313r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64313r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64313r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64313r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64313r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64313r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64313r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64313r=support
Expected behavior: https://bugs.php.net/fix.php?id=64313r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64313r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64313r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64313r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64313r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64313r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64313r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64313r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64313r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64313r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64313r=mysqlcfg
Req #64313 [Com]: DateTime DateTimeZone constructs should emit DateTimeException
Edit report at https://bugs.php.net/bug.php?id=64313edit=1
ID: 64313
Comment by: mattsch at gmail dot com
Reported by:mattsch at gmail dot com
Summary:DateTime DateTimeZone constructs should emit
DateTimeException
Status: Open
Type: Feature/Change Request
Package:Date/time related
PHP Version:5.3.22
Block user comment: N
Private report: N
New Comment:
Forget the $format part of the test script. I changed the class slightly to
show a simplified form of the problem.
Previous Comments:
[2013-02-27 18:46:31] mattsch at gmail dot com
Description:
DateTime and DateTimeZone constructs currently emit Exception but they should
really emit an exception related to their respective classes. The reason for
this is the code can run in multiple environments (ui, phpunit, etc). If I
want the exception to bubble up to the base exception in my application
environment, I want to catch it and rethrow it with an exception that
ultimately extends my app base exception. As a result, I must catch the base
php Exception class and rethrow it with the wrapper exception which extends my
base app exception. The problem comes when I try to run testcases on the class
in the phpunit environment. Since phpunit emits exceptions, catching Exception
will also catch phpunit environment exceptions which is not what I want. As a
result, I must check the instance of the exception and allow phpunit exceptions
to go through unchanged. If the DateTime and DateTimeZone classes did not
throw Exception, then this would not be a problem. In fact, I don't think any
php command should actually throw the main php Exception and should always
throw an exception that is extended from Exception to avoid problems like this.
Test script:
---
?php
class DateTimeWrapper
{
private $dateTime;
public function __construct($time = 'now', DateTimeZone $timezone =
null, $format = null)
{
$this-setDateTime($time, $timezone, $format);
}
public function setDateTime($time = 'now', DateTimeZone $timezone =
null, $format = null)
{
try {
$this-dateTime = new DateTime($time, $timezone);
}
catch (Exception $e) {
/*
PHP DateTime really shouldn't throw the catch
all Exception so the workaround is
to keep this from catching phpunit exceptions
as well so do instance checks on it.
*/
// @codeCoverageIgnoreStart
if ($e instanceof PHPUnit_Framework_Error
|| $e instanceof PHPUnit_Framework_Exception) {
throw $e;
}
// @codeCoverageIgnoreEnd
throw new DateTimeWrapperException($e-getMessage(),
$e-getCode(), $e);
}
}
}
Expected result:
php should not throw Exception directly but rather an exception that extends
Exception.
Actual result:
--
php throws Exception in places like DateTime and DateTimeZone when it should
really throw an exception like DateTimeException instead which would extend
Exception.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64313edit=1
Bug #64016 [Com]: file_get_contents does not fill up $http_response_header via HEAD method
Edit report at https://bugs.php.net/bug.php?id=64016edit=1
ID: 64016
Comment by: mattsch at gmail dot com
Reported by:anil at saog dot net
Summary:file_get_contents does not fill up
$http_response_header via HEAD method
Status: Open
Type: Bug
Package:*URL Functions
Operating System: Centos 6.2
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
$http_response_header is undefined after doing a file_get_contents on a url on
php 5.3.21 as well.
Previous Comments:
[2013-01-18 11:19:42] anil at saog dot net
Description:
PHP is compiled with option --with-curlwrappers. Whenever a HEAD request
issued with file_get_contents, $http_response_header is not filled-up but
upon calling get_headers(), variable $http_response_header auto-magically
filled up.
Test script:
---
$url = 'http://www.google.com';
$ctx = stream_context_create();
stream_context_set_option($ctx, array('http' = array('method' =
'HEAD','timeout' = 60)));
$res = file_get_contents($url, false, $ctx);
var_dump($http_response_header); // NULL
get_headers($url);
var_dump($http_response_header); // filled up correctly
Expected result:
$http_response_header filled-up correctly
Actual result:
--
$http_response_header is always NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=64016edit=1
Req #63873 [Opn-Csd]: Implement exception chaining within core classes
Edit report at https://bugs.php.net/bug.php?id=63873edit=1
ID: 63873
User updated by:mattsch at gmail dot com
Reported by:mattsch at gmail dot com
Summary:Implement exception chaining within core classes
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:Class/Object related
Operating System: Gentoo
PHP Version:5.3.20
Block user comment: N
Private report: N
New Comment:
It turns out that this is not necessary. The workaround for this is to catch
core exceptions and throw a new exception and pass the previous exception (core
exception) into the new exception. Then the exception chain won't be broken.
Previous Comments:
[2012-12-29 16:26:07] mattsch at gmail dot com
Description:
php core classes have no way of continuing the exception chain. If we are to
have proper exception chaining as implemented in the exception class in php
5.3, we should also have the ability to continue the exception chain within php
core classes to make debugging easier.
Test script:
---
?php
class MyCustomException extends Exception {}
function doStuff() {
try {
throw new InvalidArgumentException(You are doing it wrong!, 112);
} catch(Exception $e) {
try {
$pdo = new PDO('foo', 'foo', 'bar', array()); // exception
chain lost
// $pdo = new PDO('foo', 'foo', 'bar', array(), $e); // needs
additional previous exception parameter
} catch (Exception $ex) {
throw new MyCustomException(Something happened, 911, $ex);
}
}
}
try {
doStuff();
} catch(Exception $e) {
do {
printf(%s:%d %s (%d) [%s]\n, $e-getFile(), $e-getLine(),
$e-getMessage(), $e-getCode(), get_class($e));
} while($e = $e-getPrevious());
}
Expected result:
Expected result:
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
foo.php:7 You are doing it wrong! (112) [InvalidArgumentException]
Actual result:
--
Actual result:
--
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
--
Edit this bug report at https://bugs.php.net/bug.php?id=63873edit=1
Bug #63868 [Nab]: PDO construct breaks exception chain
Edit report at https://bugs.php.net/bug.php?id=63868edit=1
ID: 63868
User updated by:mattsch at gmail dot com
Reported by:mattsch at gmail dot com
Summary:PDO construct breaks exception chain
Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Gentoo
PHP Version:5.3.20
Block user comment: N
Private report: N
New Comment:
Since you declared this as not a bug quite quickly, does this mean you have no
intention on allowing an unbroken exception chain within php exceptions? If
that's the case, then why bother implementing exception chaining at all? It's
supposed to help debugging but if the chain gets broken within php core
classes, what's the point?
Previous Comments:
[2012-12-29 12:34:07] johan...@php.net
This doesn't seem like anything fitting in PDO design (and btw. this affects
any function which might throw an exception...)
[2012-12-28 18:14:50] mattsch at gmail dot com
Description:
The pdo construct has no way of continuing the exception chain. It needs
another parameter at the end so you can pass in the previous exception. For
that matter, is there any kind of effort to add exception chaining parameters
for all php classes that throw exceptions?
Test script:
---
?php
class MyCustomException extends Exception {}
function doStuff() {
try {
throw new InvalidArgumentException(You are doing it wrong!, 112);
} catch(Exception $e) {
try {
$pdo = new PDO('foo', 'foo', 'bar', array()); // exception
chain lost
// $pdo = new PDO('foo', 'foo', 'bar', array(), $e); // needs
additional previous exception parameter
} catch (Exception $ex) {
throw new MyCustomException(Something happened, 911, $ex);
}
}
}
try {
doStuff();
} catch(Exception $e) {
do {
printf(%s:%d %s (%d) [%s]\n, $e-getFile(), $e-getLine(),
$e-getMessage(), $e-getCode(), get_class($e));
} while($e = $e-getPrevious());
}
Expected result:
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
foo.php:7 You are doing it wrong! (112) [InvalidArgumentException]
Actual result:
--
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
--
Edit this bug report at https://bugs.php.net/bug.php?id=63868edit=1
[PHP-BUG] Req #63873 [NEW]: Implement exception chaining within core classes
From: mattsch at gmail dot com
Operating system: Gentoo
PHP version: 5.3.20
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:Implement exception chaining within core classes
Description:
php core classes have no way of continuing the exception chain. If we are
to have proper exception chaining as implemented in the exception class in
php 5.3, we should also have the ability to continue the exception chain
within php core classes to make debugging easier.
Test script:
---
?php
class MyCustomException extends Exception {}
function doStuff() {
try {
throw new InvalidArgumentException(You are doing it wrong!,
112);
} catch(Exception $e) {
try {
$pdo = new PDO('foo', 'foo', 'bar', array()); // exception
chain lost
// $pdo = new PDO('foo', 'foo', 'bar', array(), $e); //
needs additional previous exception parameter
} catch (Exception $ex) {
throw new MyCustomException(Something happened, 911,
$ex);
}
}
}
try {
doStuff();
} catch(Exception $e) {
do {
printf(%s:%d %s (%d) [%s]\n, $e-getFile(), $e-getLine(),
$e-getMessage(), $e-getCode(), get_class($e));
} while($e = $e-getPrevious());
}
Expected result:
Expected result:
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
foo.php:7 You are doing it wrong! (112) [InvalidArgumentException]
Actual result:
--
Actual result:
--
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
--
Edit bug report at https://bugs.php.net/bug.php?id=63873edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63873r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63873r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63873r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63873r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63873r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63873r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63873r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63873r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63873r=support
Expected behavior: https://bugs.php.net/fix.php?id=63873r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63873r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63873r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63873r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63873r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63873r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63873r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63873r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63873r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63873r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63873r=mysqlcfg
[PHP-BUG] Bug #63868 [NEW]: PDO construct breaks exception chain
From: mattsch at gmail dot com
Operating system: Gentoo
PHP version: 5.3.20
Package: PDO related
Bug Type: Bug
Bug description:PDO construct breaks exception chain
Description:
The pdo construct has no way of continuing the exception chain. It needs
another parameter at the end so you can pass in the previous exception.
For that matter, is there any kind of effort to add exception chaining
parameters for all php classes that throw exceptions?
Test script:
---
?php
class MyCustomException extends Exception {}
function doStuff() {
try {
throw new InvalidArgumentException(You are doing it wrong!,
112);
} catch(Exception $e) {
try {
$pdo = new PDO('foo', 'foo', 'bar', array()); // exception
chain lost
// $pdo = new PDO('foo', 'foo', 'bar', array(), $e); //
needs additional previous exception parameter
} catch (Exception $ex) {
throw new MyCustomException(Something happened, 911,
$ex);
}
}
}
try {
doStuff();
} catch(Exception $e) {
do {
printf(%s:%d %s (%d) [%s]\n, $e-getFile(), $e-getLine(),
$e-getMessage(), $e-getCode(), get_class($e));
} while($e = $e-getPrevious());
}
Expected result:
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
foo.php:7 You are doing it wrong! (112) [InvalidArgumentException]
Actual result:
--
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
--
Edit bug report at https://bugs.php.net/bug.php?id=63868edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63868r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63868r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63868r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63868r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63868r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63868r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63868r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63868r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63868r=support
Expected behavior: https://bugs.php.net/fix.php?id=63868r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63868r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63868r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63868r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63868r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63868r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63868r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63868r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63868r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63868r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63868r=mysqlcfg
Bug #63766 [Nab]: sftp upload CURLOPT_URL errors with code 79 with directory path
Edit report at https://bugs.php.net/bug.php?id=63766edit=1 ID: 63766 User updated by:mattsch at gmail dot com Reported by:mattsch at gmail dot com Summary:sftp upload CURLOPT_URL errors with code 79 with directory path Status: Not a bug Type: Bug Package:cURL related Operating System: Gentoo PHP Version:5.4.9 Block user comment: N Private report: N New Comment: That does not explain why it fails when you try to upload to a directory. So what you're saying is this is not a bug because it's not possible to do this with curl and you must always specify a url with a filename to upload a file? And if that's the case, why is it not possible to upload a file to a directory? Previous Comments: [2012-12-18 07:20:48] paj...@php.net See previous comments [2012-12-18 07:11:27] bag...@php.net The CURLOPT_URL option is of course to generically set a URL to work with. libcurl accepts whatever URL you set and will try to work on it once you ask curl to perform on it. A URL that ends with a slash is treated as a directory by libcurl when you're downloading something from it. It will then (depending on protocol) ask for a directory listing instead of trying to fetch a file with that name. libcurl assumes the users knows what (s)he is doing and will try to perform the requested operation on the given URL. Uploading to a directory name is probably going to fail on most systems. [2012-12-17 14:48:16] mattsch at gmail dot com Could you elaborate as to why this would be a bad url? The documentation on the curl website seems to indicate that you can specify a url without a filename at the end but then the examples are not specific to upload: http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTURL [2012-12-17 12:17:00] bag...@php.net This is not a libcurl bug. If you think about it for a while, libcurl doesn't know the 'foo' name, it is only given the (bad) URL and it cannot but to fail in this case. I'm also convinced you can see the same problem with other protocols than SFTP for the same reason. [2012-12-17 01:23:46] ahar...@php.net Reopened per previous comments, although I wonder if this might be a libcurl issue rather than a PHP one. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63766 -- Edit this bug report at https://bugs.php.net/bug.php?id=63766edit=1
Bug #63766 [Nab]: sftp upload CURLOPT_URL errors with code 79 with directory path
Edit report at https://bugs.php.net/bug.php?id=63766edit=1
ID: 63766
User updated by:mattsch at gmail dot com
Reported by:mattsch at gmail dot com
Summary:sftp upload CURLOPT_URL errors with code 79 with
directory path
Status: Not a bug
Type: Bug
Package:cURL related
Operating System: Gentoo
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
In addition, if I modify the test script and it with a slash at the end, it
also fails in the same way:
upload('sftp://domain.tld:/tmp/');
Previous Comments:
[2012-12-18 15:49:54] mattsch at gmail dot com
That does not explain why it fails when you try to upload to a directory. So
what you're saying is this is not a bug because it's not possible to do this
with curl and you must always specify a url with a filename to upload a file?
And if that's the case, why is it not possible to upload a file to a directory?
[2012-12-18 07:20:48] paj...@php.net
See previous comments
[2012-12-18 07:11:27] bag...@php.net
The CURLOPT_URL option is of course to generically set a URL to work with.
libcurl accepts whatever URL you set and will try to work on it once you ask
curl to perform on it.
A URL that ends with a slash is treated as a directory by libcurl when you're
downloading something from it. It will then (depending on protocol) ask for a
directory listing instead of trying to fetch a file with that name.
libcurl assumes the users knows what (s)he is doing and will try to perform the
requested operation on the given URL. Uploading to a directory name is probably
going to fail on most systems.
[2012-12-17 14:48:16] mattsch at gmail dot com
Could you elaborate as to why this would be a bad url? The documentation on
the curl website seems to indicate that you can specify a url without a
filename at the end but then the examples are not specific to upload:
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTURL
[2012-12-17 12:17:00] bag...@php.net
This is not a libcurl bug. If you think about it for a while, libcurl doesn't
know the 'foo' name, it is only given the (bad) URL and it cannot but to fail
in
this case.
I'm also convinced you can see the same problem with other protocols than SFTP
for the same reason.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63766
--
Edit this bug report at https://bugs.php.net/bug.php?id=63766edit=1
Bug #63766 [Nab]: sftp upload CURLOPT_URL errors with code 79 with directory path
Edit report at https://bugs.php.net/bug.php?id=63766edit=1
ID: 63766
User updated by:mattsch at gmail dot com
Reported by:mattsch at gmail dot com
Summary:sftp upload CURLOPT_URL errors with code 79 with
directory path
Status: Not a bug
Type: Bug
Package:cURL related
Operating System: Gentoo
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
Also the same thing happens when using scp://. What I don't understand is if I
were to upload the file on the command line with scp without specifying a
filename but rather just a destination directory, the file would upload. So
why can't I expect curl to do the same when using the same protocol?
Previous Comments:
[2012-12-18 15:55:52] mattsch at gmail dot com
In addition, if I modify the test script and it with a slash at the end, it
also fails in the same way:
upload('sftp://domain.tld:/tmp/');
[2012-12-18 15:49:54] mattsch at gmail dot com
That does not explain why it fails when you try to upload to a directory. So
what you're saying is this is not a bug because it's not possible to do this
with curl and you must always specify a url with a filename to upload a file?
And if that's the case, why is it not possible to upload a file to a directory?
[2012-12-18 07:20:48] paj...@php.net
See previous comments
[2012-12-18 07:11:27] bag...@php.net
The CURLOPT_URL option is of course to generically set a URL to work with.
libcurl accepts whatever URL you set and will try to work on it once you ask
curl to perform on it.
A URL that ends with a slash is treated as a directory by libcurl when you're
downloading something from it. It will then (depending on protocol) ask for a
directory listing instead of trying to fetch a file with that name.
libcurl assumes the users knows what (s)he is doing and will try to perform the
requested operation on the given URL. Uploading to a directory name is probably
going to fail on most systems.
[2012-12-17 14:48:16] mattsch at gmail dot com
Could you elaborate as to why this would be a bad url? The documentation on
the curl website seems to indicate that you can specify a url without a
filename at the end but then the examples are not specific to upload:
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTURL
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63766
--
Edit this bug report at https://bugs.php.net/bug.php?id=63766edit=1
Bug #63766 [Opn]: sftp upload CURLOPT_URL errors with code 79 with directory path
Edit report at https://bugs.php.net/bug.php?id=63766edit=1 ID: 63766 User updated by:mattsch at gmail dot com Reported by:mattsch at gmail dot com Summary:sftp upload CURLOPT_URL errors with code 79 with directory path Status: Open Type: Bug Package:cURL related Operating System: Gentoo PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Could you elaborate as to why this would be a bad url? The documentation on the curl website seems to indicate that you can specify a url without a filename at the end but then the examples are not specific to upload: http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTURL Previous Comments: [2012-12-17 12:17:00] bag...@php.net This is not a libcurl bug. If you think about it for a while, libcurl doesn't know the 'foo' name, it is only given the (bad) URL and it cannot but to fail in this case. I'm also convinced you can see the same problem with other protocols than SFTP for the same reason. [2012-12-17 01:23:46] ahar...@php.net Reopened per previous comments, although I wonder if this might be a libcurl issue rather than a PHP one. [2012-12-14 22:50:27] mattsch at gmail dot com foo designates a file and not a directory. Perhaps my test script should have been more clear by using a file extension like .txt or something. The file I am trying to upload is being uploaded to a directory that already exists on the remote server. [2012-12-14 22:47:01] mattsch at gmail dot com This is a bug. I am not trying to upload anything recursively. I am simply trying to upload one file to a directory. When I don't specify the target filename on the url, I expect that the target file created on the remote server is the same name as the filename that I am uploading. [2012-12-14 08:39:20] paj...@php.net CURL cannot upload directory (aka recursively). However it can create missing directories in a path if necessary using the create dir option. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63766 -- Edit this bug report at https://bugs.php.net/bug.php?id=63766edit=1
Bug #63766 [Nab]: sftp upload CURLOPT_URL errors with code 79 with directory path
Edit report at https://bugs.php.net/bug.php?id=63766edit=1
ID: 63766
User updated by:mattsch at gmail dot com
Reported by:mattsch at gmail dot com
Summary:sftp upload CURLOPT_URL errors with code 79 with
directory path
Status: Not a bug
Type: Bug
Package:cURL related
Operating System: Gentoo
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
This is a bug. I am not trying to upload anything recursively. I am simply
trying to upload one file to a directory. When I don't specify the target
filename on the url, I expect that the target file created on the remote server
is the same name as the filename that I am uploading.
Previous Comments:
[2012-12-14 08:39:20] paj...@php.net
CURL cannot upload directory (aka recursively).
However it can create missing directories in a path if necessary using the
create
dir option.
[2012-12-14 06:55:24] mattsch at gmail dot com
Description:
When specifying a url in CURLOPT_URL with a directory path only using the sftp
protocol, the upload will always fail with error code 79 (An unspecified error
occurred during the SSH session). If you change the CURLOPT_URL to be the same
path but add a filename at the end of the directory path, the upload will
succeed.
emerge -pv php:5.4
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ~] dev-lang/php-5.4.9:5.4 USE=apache2 bcmath bzip2 calendar cjk
cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd gdbm gmp hash
iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls pcntl pdo phar posix
readline session simplexml snmp soap sockets spell sqlite ssl sysvipc threads
tidy tokenizer truetype unicode wddx xml xmlwriter xpm xsl zip zlib -berkdb
-cdb -cgi -debug -doc -embed -enchant -firebird -flatfile -fpm (-frontbase)
-imap -inifile -intl -iodbc -kerberos (-kolab) -ldap-sasl -libedit -mssql
-oci8-instant-client -odbc -pic -postgres -qdbm -recode (-selinux) -sharedmem
(-sybase-ct) -xmlreader -xmlrpc 0 kB
emerge -pv curl
These are the packages that would be merged, in order:
Calculating dependencies e - ... done!
[ebuild R ~] net-misc/curl-7.28.1 USE=idn ipv6 nonblocking ssh ssl
threads -adns -kerberos -ldap -metalink -rtmp -static-libs {-test}
CURL_SSL=openssl -axtls -cyassl -gnutls -nss -polarssl 0 kB
emerge -pv libssh2
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ~] net-libs/libssh2-1.4.3 USE=zlib -gcrypt -static-libs
{-test} 0 kB
curl -V
curl 7.28.1 (x86_64-pc-linux-gnu) libcurl/7.28.1 OpenSSL/1.0.0j zlib/1.2.7
libidn/1.25 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp
sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz
Test script:
---
?php
function upload($url)
{
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_UPLOAD, 1);
curl_setopt($ch, CURLOPT_INFILE, fopen('/tmp/foo', 'r'));
curl_setopt($ch, CURLOPT_INFILESIZE, filesize('/tmp/foo'));
curl_setopt($ch, CURLOPT_USERPWD, 'user:password');
curl_exec($ch);
echo curl_errno($ch) . \n;
}
// prints 79 -- should print 0
upload('sftp://domain.tld:/tmp');
// prints 0
upload('sftp://domain.tld:/tmp/foo');
Expected result:
0
0
Actual result:
--
79
0
--
Edit this bug report at https://bugs.php.net/bug.php?id=63766edit=1
Bug #63766 [Nab]: sftp upload CURLOPT_URL errors with code 79 with directory path
Edit report at https://bugs.php.net/bug.php?id=63766edit=1
ID: 63766
User updated by:mattsch at gmail dot com
Reported by:mattsch at gmail dot com
Summary:sftp upload CURLOPT_URL errors with code 79 with
directory path
Status: Not a bug
Type: Bug
Package:cURL related
Operating System: Gentoo
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
foo designates a file and not a directory. Perhaps my test script should
have been more clear by using a file extension like .txt or something. The
file I am trying to upload is being uploaded to a directory that already exists
on the remote server.
Previous Comments:
[2012-12-14 22:47:01] mattsch at gmail dot com
This is a bug. I am not trying to upload anything recursively. I am simply
trying to upload one file to a directory. When I don't specify the target
filename on the url, I expect that the target file created on the remote server
is the same name as the filename that I am uploading.
[2012-12-14 08:39:20] paj...@php.net
CURL cannot upload directory (aka recursively).
However it can create missing directories in a path if necessary using the
create
dir option.
[2012-12-14 06:55:24] mattsch at gmail dot com
Description:
When specifying a url in CURLOPT_URL with a directory path only using the sftp
protocol, the upload will always fail with error code 79 (An unspecified error
occurred during the SSH session). If you change the CURLOPT_URL to be the same
path but add a filename at the end of the directory path, the upload will
succeed.
emerge -pv php:5.4
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ~] dev-lang/php-5.4.9:5.4 USE=apache2 bcmath bzip2 calendar cjk
cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd gdbm gmp hash
iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls pcntl pdo phar posix
readline session simplexml snmp soap sockets spell sqlite ssl sysvipc threads
tidy tokenizer truetype unicode wddx xml xmlwriter xpm xsl zip zlib -berkdb
-cdb -cgi -debug -doc -embed -enchant -firebird -flatfile -fpm (-frontbase)
-imap -inifile -intl -iodbc -kerberos (-kolab) -ldap-sasl -libedit -mssql
-oci8-instant-client -odbc -pic -postgres -qdbm -recode (-selinux) -sharedmem
(-sybase-ct) -xmlreader -xmlrpc 0 kB
emerge -pv curl
These are the packages that would be merged, in order:
Calculating dependencies e - ... done!
[ebuild R ~] net-misc/curl-7.28.1 USE=idn ipv6 nonblocking ssh ssl
threads -adns -kerberos -ldap -metalink -rtmp -static-libs {-test}
CURL_SSL=openssl -axtls -cyassl -gnutls -nss -polarssl 0 kB
emerge -pv libssh2
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ~] net-libs/libssh2-1.4.3 USE=zlib -gcrypt -static-libs
{-test} 0 kB
curl -V
curl 7.28.1 (x86_64-pc-linux-gnu) libcurl/7.28.1 OpenSSL/1.0.0j zlib/1.2.7
libidn/1.25 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp
sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz
Test script:
---
?php
function upload($url)
{
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_UPLOAD, 1);
curl_setopt($ch, CURLOPT_INFILE, fopen('/tmp/foo', 'r'));
curl_setopt($ch, CURLOPT_INFILESIZE, filesize('/tmp/foo'));
curl_setopt($ch, CURLOPT_USERPWD, 'user:password');
curl_exec($ch);
echo curl_errno($ch) . \n;
}
// prints 79 -- should print 0
upload('sftp://domain.tld:/tmp');
// prints 0
upload('sftp://domain.tld:/tmp/foo');
Expected result:
0
0
Actual result:
--
79
0
--
Edit this bug report at https://bugs.php.net/bug.php?id=63766edit=1
[PHP-BUG] Bug #63766 [NEW]: sftp upload CURLOPT_URL errors with code 79 with directory path
From: mattsch at gmail dot com
Operating system: Gentoo
PHP version: 5.4.9
Package: cURL related
Bug Type: Bug
Bug description:sftp upload CURLOPT_URL errors with code 79 with directory path
Description:
When specifying a url in CURLOPT_URL with a directory path only using the
sftp protocol, the upload will always fail with error code 79 (An
unspecified error occurred during the SSH session). If you change the
CURLOPT_URL to be the same path but add a filename at the end of the
directory path, the upload will succeed.
emerge -pv php:5.4
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ~] dev-lang/php-5.4.9:5.4 USE=apache2 bcmath bzip2 calendar
cjk cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd gdbm gmp
hash iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls pcntl pdo phar
posix readline session simplexml snmp soap sockets spell sqlite ssl sysvipc
threads tidy tokenizer truetype unicode wddx xml xmlwriter xpm xsl zip zlib
-berkdb -cdb -cgi -debug -doc -embed -enchant -firebird -flatfile -fpm
(-frontbase) -imap -inifile -intl -iodbc -kerberos (-kolab) -ldap-sasl
-libedit -mssql -oci8-instant-client -odbc -pic -postgres -qdbm -recode
(-selinux) -sharedmem (-sybase-ct) -xmlreader -xmlrpc 0 kB
emerge -pv curl
These are the packages that would be merged, in order:
Calculating dependencies e - ... done!
[ebuild R ~] net-misc/curl-7.28.1 USE=idn ipv6 nonblocking ssh ssl
threads -adns -kerberos -ldap -metalink -rtmp -static-libs {-test}
CURL_SSL=openssl -axtls -cyassl -gnutls -nss -polarssl 0 kB
emerge -pv libssh2
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ~] net-libs/libssh2-1.4.3 USE=zlib -gcrypt -static-libs
{-test} 0 kB
curl -V
curl 7.28.1 (x86_64-pc-linux-gnu) libcurl/7.28.1 OpenSSL/1.0.0j zlib/1.2.7
libidn/1.25 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp
scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz
Test script:
---
?php
function upload($url)
{
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_UPLOAD, 1);
curl_setopt($ch, CURLOPT_INFILE, fopen('/tmp/foo', 'r'));
curl_setopt($ch, CURLOPT_INFILESIZE, filesize('/tmp/foo'));
curl_setopt($ch, CURLOPT_USERPWD, 'user:password');
curl_exec($ch);
echo curl_errno($ch) . \n;
}
// prints 79 -- should print 0
upload('sftp://domain.tld:/tmp');
// prints 0
upload('sftp://domain.tld:/tmp/foo');
Expected result:
0
0
Actual result:
--
79
0
--
Edit bug report at https://bugs.php.net/bug.php?id=63766edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63766r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63766r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63766r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63766r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63766r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63766r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63766r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63766r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63766r=support
Expected behavior: https://bugs.php.net/fix.php?id=63766r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63766r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63766r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63766r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63766r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63766r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63766r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63766r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63766r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63766r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63766r=mysqlcfg
Req #44392 [Com]: getFilePointer() for Childs of SplFileObject
Edit report at https://bugs.php.net/bug.php?id=44392edit=1
ID: 44392
Comment by: mattsch at gmail dot com
Reported by:php at benjaminschulz dot com
Summary:getFilePointer() for Childs of SplFileObject
Status: Open
Type: Feature/Change Request
Package:SPL related
PHP Version:5.3CVS-2008-03-10 (CVS)
Block user comment: N
Private report: N
New Comment:
I agree that this method should also be public. Please implement this method
ASAP.
Previous Comments:
[2012-12-09 01:26:59] le...@php.net
I don't see why this method shouldn't be public. I vote for extending its
visibility to public.
[2012-11-20 23:38:18] mattsch at gmail dot com
What's the status of this bug? SplFileObject is supposed to be an OO version
of fopen but it's quite useless to pass into other functions like curl when
those functions expect a resource.
Example:
$splFileObject = new SplFileObject('/tmp/foo', 'r');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'sftp://server.com/folder/');
curl_setopt($ch, CURLOPT_UPLOAD, 1);
curl_setopt($ch, CURLOPT_INFILE, $splFileObject); # -- won't work, must be
file resource
curl_setopt($ch, CURLOPT_INFILESIZE, filesize($localfile));
curl_exec ($ch);
curl_close($ch);
[2008-11-14 23:49:33] jordan dot raub at dataxltd dot com
add a protected member function to SplFileObject so that extending classes can
have more control of the file handle... patch included against php5.2.6..
--- php-5.2.6/ext/spl/spl_directory.c 2008-02-13 04:23:26.0 -0800
+++ php52GetResource/ext/spl/spl_directory.c2008-11-14 13:22:17.0
-0800
@@ -2218,6 +2218,15 @@
}
} /* }}} */
+/* {{{ proto void SplFileObject::getFileResource()
+ Seek to specified line */
+SPL_METHOD(SplFileObject, getFileResource)
+{
+ spl_filesystem_object *intern =
(spl_filesystem_object*)zend_object_store_get_object(getThis() TSRMLS_CC);
+
+ php_stream_to_zval(intern-u.file.stream, return_value);
+} /* }}} */
+
/* {{{ Function/Class/Method definitions */
static
ZEND_BEGIN_ARG_INFO_EX(arginfo_file_object___construct, 0, 0, 1)
@@ -2310,6 +2319,7 @@
SPL_ME(SplFileObject, getMaxLineLen, NULL, ZEND_ACC_PUBLIC)
SPL_ME(SplFileObject, hasChildren,NULL, ZEND_ACC_PUBLIC)
SPL_ME(SplFileObject, getChildren,NULL, ZEND_ACC_PUBLIC)
+ SPL_ME(SplFileObject, getFileResource,NULL, ZEND_ACC_PROTECTED)
SPL_ME(SplFileObject, seek, arginfo_file_object_seek,
ZEND_ACC_PUBLIC)
/* mappings */
SPL_MA(SplFileObject, getCurrentLine, SplFileObject, fgets, NULL,
ZEND_ACC_PUBLIC)
[2008-03-10 14:45:49] php at benjaminschulz dot com
Description:
It would be nice if it would be possible to get the underlying resource handle
of an SplFileObject to be able to add stream filters on the file. Sadly the URI
parser in PHP seems to be broken and URIs with filters like
php://filter/read=convert.iconv.ISO-8859-15/UTF-8/resource=... cannot be used
(encoding the slash doesn't work either (%2F)) therefore it would be nice if
one could access the underlying resource handle f.e. by providing a protected
$fp in SplFileObject one could use in a child class then and do the
stream_filter_append() there.
--
Edit this bug report at https://bugs.php.net/bug.php?id=44392edit=1
Req #44392 [Com]: getFilePointer() for Childs of SplFileObject
Edit report at https://bugs.php.net/bug.php?id=44392edit=1
ID: 44392
Comment by: mattsch at gmail dot com
Reported by:php at benjaminschulz dot com
Summary:getFilePointer() for Childs of SplFileObject
Status: Open
Type: Feature/Change Request
Package:SPL related
PHP Version:5.3CVS-2008-03-10 (CVS)
Block user comment: N
Private report: N
New Comment:
What's the status of this bug? SplFileObject is supposed to be an OO version
of fopen but it's quite useless to pass into other functions like curl when
those functions expect a resource.
Example:
$splFileObject = new SplFileObject('/tmp/foo', 'r');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'sftp://server.com/folder/');
curl_setopt($ch, CURLOPT_UPLOAD, 1);
curl_setopt($ch, CURLOPT_INFILE, $splFileObject); # -- won't work, must be
file resource
curl_setopt($ch, CURLOPT_INFILESIZE, filesize($localfile));
curl_exec ($ch);
curl_close($ch);
Previous Comments:
[2008-11-14 23:49:33] jordan dot raub at dataxltd dot com
add a protected member function to SplFileObject so that extending classes can
have more control of the file handle... patch included against php5.2.6..
--- php-5.2.6/ext/spl/spl_directory.c 2008-02-13 04:23:26.0 -0800
+++ php52GetResource/ext/spl/spl_directory.c2008-11-14 13:22:17.0
-0800
@@ -2218,6 +2218,15 @@
}
} /* }}} */
+/* {{{ proto void SplFileObject::getFileResource()
+ Seek to specified line */
+SPL_METHOD(SplFileObject, getFileResource)
+{
+ spl_filesystem_object *intern =
(spl_filesystem_object*)zend_object_store_get_object(getThis() TSRMLS_CC);
+
+ php_stream_to_zval(intern-u.file.stream, return_value);
+} /* }}} */
+
/* {{{ Function/Class/Method definitions */
static
ZEND_BEGIN_ARG_INFO_EX(arginfo_file_object___construct, 0, 0, 1)
@@ -2310,6 +2319,7 @@
SPL_ME(SplFileObject, getMaxLineLen, NULL, ZEND_ACC_PUBLIC)
SPL_ME(SplFileObject, hasChildren,NULL, ZEND_ACC_PUBLIC)
SPL_ME(SplFileObject, getChildren,NULL, ZEND_ACC_PUBLIC)
+ SPL_ME(SplFileObject, getFileResource,NULL, ZEND_ACC_PROTECTED)
SPL_ME(SplFileObject, seek, arginfo_file_object_seek,
ZEND_ACC_PUBLIC)
/* mappings */
SPL_MA(SplFileObject, getCurrentLine, SplFileObject, fgets, NULL,
ZEND_ACC_PUBLIC)
[2008-03-10 14:45:49] php at benjaminschulz dot com
Description:
It would be nice if it would be possible to get the underlying resource handle
of an SplFileObject to be able to add stream filters on the file. Sadly the URI
parser in PHP seems to be broken and URIs with filters like
php://filter/read=convert.iconv.ISO-8859-15/UTF-8/resource=... cannot be used
(encoding the slash doesn't work either (%2F)) therefore it would be nice if
one could access the underlying resource handle f.e. by providing a protected
$fp in SplFileObject one could use in a child class then and do the
stream_filter_append() there.
--
Edit this bug report at https://bugs.php.net/bug.php?id=44392edit=1
Bug #59866 [Com]: http_api.c:256: error: too few arguments to function 'php_ob_handler_used
Edit report at https://bugs.php.net/bug.php?id=59866edit=1 ID: 59866 Comment by: mattsch at gmail dot com Reported by:mattsch at gmail dot com Summary:http_api.c:256: error: too few arguments to function 'php_ob_handler_used Status: Closed Type: Bug Package:pecl_http Operating System: Gentoo Linux PHP Version:5.3.6 Assigned To:felipe Block user comment: N Private report: N New Comment: Which version is it fixed in? I don't see any new stable version. Previous Comments: [2011-10-12 21:22:23] fel...@php.net Try a newer version. [2011-08-23 06:34:56] bombadil at bosqueviejo dot net Versión 1.7.0 works fine. You can write this: pecl install pecl_http-1.7.0 to install it. [2011-07-22 11:11:22] mattsch at gmail dot com Description: pecl-http-1.7.1 refuses to compile with either php 5.2 or php 5.3: /var/tmp/portage/dev-php5/pecl-http-1.7.1/work/php5.3/http_api.c: In function '_http_exit_ex': /var/tmp/portage/dev-php5/pecl-http-1.7.1/work/php5.3/http_api.c:256: error: too few arguments to function 'php_ob_handler_used' /var/tmp/portage/dev-php5/pecl-http-1.7.1/work/php5.3/http_api.c:256: error: too few arguments to function 'php_ob_handler_used' make: *** [http_api.lo] Error 1 make: *** Waiting for unfinished jobs Additional information (environmenent, etc): https://bugs.gentoo.org/show_bug.cgi?id=368595 Expected result: pecl-http compiles Actual result: -- pecl-http does not compile -- Edit this bug report at https://bugs.php.net/bug.php?id=59866edit=1
#42632 [NEW]: PDO fetch doesn't preserve case
From: mattsch at gmail dot com
Operating system: Gentoo Linux
PHP version: 5.2.4
PHP Bug Type: PDO related
Bug description: PDO fetch doesn't preserve case
Description:
PDO fetch doesn't preserve the case of the column. I don't know if this
is a feature or if it is a bug, but if it is a feature since the
beginning of PDO, could I also suggest that another flag be added for PDO
fetch to tell it to preserve the case?
Reproduce code:
---
?php
try {
$pdo = new PDO(pgsql:host={$host};dbname={$database}, $user,
$password);
$pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo-query(SET search_path to {$schema});
$accountState = $pdo-prepare('
SELECT id AS accountId
FROM account
WHERE id = ?
');
$accountState-bindParam(1, $id, PDO::PARAM_INT);
$accountState-execute();
$getAccount = $accountState-fetch(PDO::FETCH_OBJ);
$accountState-closeCursor();
var_dump($getAccount);
} catch (Exception $e){
print An error occurred: {$e-getMessage()};
}
?
Expected result:
object(stdClass)#8 (1) {
[accountId]=
int(339)
}
Actual result:
--
object(stdClass)#8 (1) {
[accountid]=
int(339)
}
--
Edit bug report at http://bugs.php.net/?id=42632edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42632r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42632r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42632r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42632r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42632r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42632r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42632r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42632r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42632r=support
Expected behavior:http://bugs.php.net/fix.php?id=42632r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42632r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42632r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42632r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42632r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42632r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42632r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42632r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42632r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42632r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42632r=mysqlcfg
#42351 [NEW]: Unable to create dates with years = -10000 and = 10000
From: mattsch at gmail dot com
Operating system: Gentoo Linux 2007.0
PHP version: 5.2.4RC2
PHP Bug Type: Date/time related
Bug description: Unable to create dates with years = -1 and = 1
Description:
I am unable to create dates with years = -1 and = 1. ISO
8601:2004E allows for this under Expanded representations:
http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func=doc.Fetchnodeid=4021199
ISO 8601:2004(E)
14 © ISO 2004 All rights reserved
4.1.2.4 Expanded representations
If, by agreement, expanded representations are used, the formats shall be
as specified below. The
interchange parties shall agree the additional number of digits in the
time element year. In the examples below
it has been agreed to expand the time element year with two digits.
a) A specific day
Basic format: ±YMMDD Example: +0019850412
Extended format: ±Y-MM-DD Example: +001985-04-12
b) A specific month
Basic format: ±Y-MM Example: +001985-04
Extended format: not applicable
c) A specific year
Basic format: ±Y Example: +001985
Extended format: not applicable
d) A specific century
Basic format: ±YYY Example: +0019
Extended format: not applicable
Reproduce code:
---
Negative year:
?php
$date = new DateTime('-1-01-01 00:00:00');
echo $date-format('Y-m-d H:i:s');
?
Positive year:
?php
$date = new DateTime('1-01-01 00:00:00');
echo $date-format('Y-m-d H:i:s');
?
Expected result:
Negative year outputs:
-1-01-01 00:00:00
Positive year outputs:
1-01-01 00:00:00
Actual result:
--
Negative year outputs:
2000-01-01 00:00:00
Positive year outputs:
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct(): Failed to parse time string (1-01-01
00:00:00) at position 12 (0): Double time specification' in /test.php:5
Stack trace:
#0 /test.php(5): DateTime-__construct('1-01-01 00:...')
#1 {main}
thrown in /test.php on line 5
--
Edit bug report at http://bugs.php.net/?id=42351edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42351r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42351r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42351r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42351r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42351r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42351r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42351r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42351r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42351r=support
Expected behavior:http://bugs.php.net/fix.php?id=42351r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42351r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42351r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42351r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42351r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42351r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42351r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42351r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42351r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42351r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42351r=mysqlcfg
#42251 [Bgs]: Add functionName throws Exception syntax
ID: 42251
User updated by: mattsch at gmail dot com
Reported By: mattsch at gmail dot com
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Gentoo Linux
PHP Version: 5.2.4RC1
New Comment:
Apparently php internals is not searchable. Could you humble me with a
link?
Previous Comments:
[2007-08-09 07:42:49] [EMAIL PROTECTED]
While the current Exception system was designed it was decided not
having that syntax. Please search the archives of the internals list for
more.
[2007-08-08 22:40:48] mattsch at gmail dot com
Description:
It just came to my attention today that there is a function-based
Exception syntax in Java that would be very beneficial to have in php:
Example in Java:
public boolean foo(String bar) throws Exception {
//Run commands that may throw exceptions
}
Proposal in PHP:
public function foo($bar) throws Exception {
//Run commands that may throw exceptions
}
This will ensure that the function is only called within a try/catch
block and if it's not, it can throw an uncaught exception or throw an
error of some sort. This would be very helpful because when someone who
didn't develop the function (a different developer) trys to use the
function outside of a try/catch block, he or she will be warned
immediately.
--
Edit this bug report at http://bugs.php.net/?id=42251edit=1
#42251 [NEW]: Add functionName throws Exception syntax
From: mattsch at gmail dot com
Operating system: Gentoo Linux
PHP version: 5.2.4RC1
PHP Bug Type: Feature/Change Request
Bug description: Add functionName throws Exception syntax
Description:
It just came to my attention today that there is a function-based
Exception syntax in Java that would be very beneficial to have in php:
Example in Java:
public boolean foo(String bar) throws Exception {
//Run commands that may throw exceptions
}
Proposal in PHP:
public function foo($bar) throws Exception {
//Run commands that may throw exceptions
}
This will ensure that the function is only called within a try/catch block
and if it's not, it can throw an uncaught exception or throw an error of
some sort. This would be very helpful because when someone who didn't
develop the function (a different developer) trys to use the function
outside of a try/catch block, he or she will be warned immediately.
--
Edit bug report at http://bugs.php.net/?id=42251edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42251r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42251r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42251r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42251r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42251r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42251r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42251r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42251r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42251r=support
Expected behavior:http://bugs.php.net/fix.php?id=42251r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42251r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42251r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42251r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42251r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42251r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42251r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42251r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42251r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42251r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42251r=mysqlcfg
#42151 [NEW]: __destruct functions not called after catching a SoapFault exception
From: mattsch at gmail dot com
Operating system: Gentoo Linux
PHP version: 5.2.3
PHP Bug Type: SOAP related
Bug description: __destruct functions not called after catching a SoapFault
exception
Description:
All __destruct functions of all objects in memory are not called if a
SoapFault exception is thrown and caught.
Reproduce code:
---
?php
class foo {
function __construct(){
$foo = new SoapClient('http://php.net/problem_file.wsdl');
}
function __destruct(){
echo 'I never get executed.' . \n;
}
}
class bar {
function __destruct(){
echo 'I don\'t get executed either.' . \n;
}
}
try {
$bar = new bar();
$foo = new foo();
} catch (Exception $e){
echo $e-getMessage() . \n;
}
?
Expected result:
SOAP-ERROR: Parsing WSDL: Couldn't load from
'http://php.net/problem_file.wsdl'
I never get executed.
I don't get executed either.
Actual result:
--
SOAP-ERROR: Parsing WSDL: Couldn't load from
'http://php.net/problem_file.wsdl'
--
Edit bug report at http://bugs.php.net/?id=42151edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42151r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42151r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42151r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42151r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42151r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42151r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42151r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42151r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42151r=support
Expected behavior:http://bugs.php.net/fix.php?id=42151r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42151r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42151r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42151r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42151r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42151r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42151r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42151r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42151r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42151r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42151r=mysqlcfg
#42115 [NEW]: Should not allow static keyword before visibility keyword
From: mattsch at gmail dot com
Operating system: Gentoo Linux
PHP version: 5.2.3
PHP Bug Type: Class/Object related
Bug description: Should not allow static keyword before visibility keyword
Description:
Contrary to the documentation, you're allowed to put the static keyword
before the visibility keyword. Shouldn't this throw an E_STRICT warning?
Reproduce code:
---
?
class foo {
static public function bar($foo){
echo $foo;
}
}
foo::bar('test');
?
Expected result:
E_STRICT: You cannot declare static before a visibility keyword.
Actual result:
--
Echoes test without warning.
--
Edit bug report at http://bugs.php.net/?id=42115edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42115r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42115r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42115r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42115r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42115r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42115r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42115r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42115r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42115r=support
Expected behavior:http://bugs.php.net/fix.php?id=42115r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42115r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42115r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42115r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42115r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42115r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42115r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42115r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42115r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42115r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42115r=mysqlcfg
#42115 [Opn]: Should not allow static keyword before visibility keyword
ID: 42115
User updated by: mattsch at gmail dot com
Reported By: mattsch at gmail dot com
Status: Open
Bug Type: Class/Object related
Operating System: Gentoo Linux
PHP Version: 5.2.3
New Comment:
I don't argue that php is a loosely typed language but it does have
rules and it should either adhere by them or change the rules.
Currently the documentation says that static must come after
visibility:
http://www.php.net/manual/en/language.oop5.static.php
The static declaration must be after the visibility declaration.
So either emit an E_STRICT warning or change the documentation to
include this syntax as well.
Previous Comments:
[2007-07-27 02:27:14] judas dot iscariote at gmail dot com
No, PHP is a dynamic language, I dont see why this should raise any
kind of error
1. does not cause any problem.
2.it is perfectly valid code.
[2007-07-26 20:14:20] mattsch at gmail dot com
Description:
Contrary to the documentation, you're allowed to put the static keyword
before the visibility keyword. Shouldn't this throw an E_STRICT
warning?
Reproduce code:
---
?
class foo {
static public function bar($foo){
echo $foo;
}
}
foo::bar('test');
?
Expected result:
E_STRICT: You cannot declare static before a visibility keyword.
Actual result:
--
Echoes test without warning.
--
Edit this bug report at http://bugs.php.net/?id=42115edit=1
#41842 [Asn]: Cannot create years 0100 negative years with date_create or new DateTime
ID: 41842
User updated by: mattsch at gmail dot com
Reported By: mattsch at gmail dot com
Status: Assigned
Bug Type: Feature/Change Request
Operating System: Gentoo Linux 2007.0
PHP Version: 5.2.3
Assigned To: derick
New Comment:
I understand that it would be octal with a leading zero if I was
creating an integer but I'm sending it a string though so I'm not sure
how that applies. What I am referencing is the ISO 8601 standard which
does not allow years to be less than 4 digits. So years less than 100
must be padded with a zero and years less than 99 must be padded with
two zeros, etc.
http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func=doc.Fetchnodeid=4021199
Quoted from ISO 8601:2004(E):
3.6 Leading zeros
If a time element in a defined representation has a defined length,
then leading zeros shall be used as
required.
calendar year is, unless specified otherwise, represented by four
digits. Calendar years are numbered in
ascending order according to the Gregorian calendar by values in the
range [] to []. Values in
the range [] through [1582] shall only be used by mutual agreement
of the partners in information
interchange.
Calendar date
Basic format: #8722;00020412
Extended format: #8722;0002-04-12
Explanation: Expanded; four digits to represent the year.
The twelfth of April in the second year before
the year []
Previous Comments:
[2007-06-30 02:13:23] [EMAIL PROTECTED]
Sure you can. But of course a leading 0 indicates an octal number, so
099 is not a valid number.
[2007-06-29 17:22:43] mattsch at gmail dot com
I have discovered that it is also unable to create years between
and 0099.
[2007-06-28 18:17:04] [EMAIL PROTECTED]
The current code was not meant to do this, so it's not a real bug -
however, I'll check whether we can support this without breaking
something else.
[2007-06-28 16:36:44] mattsch at gmail dot com
Description:
When attempting to create a new date with a negative year and display
that date, the format function returns today's date with the timezone
offset modified and set to what the negative year should be.
Reproduce code:
---
?
$date = new DateTime('-2007-06-28');
echo $date-format(DATE_ISO8601);
?
Expected result:
Output:
-2007-06-28T11:31:19-0500
Actual result:
--
Outputs:
2007-06-28T11:31:19-2007
--
Edit this bug report at http://bugs.php.net/?id=41842edit=1
#41842 [Asn]: Cannot create years 0100 negative years with date_create or new DateTime
ID: 41842
User updated by: mattsch at gmail dot com
-Summary: Cannot create negative years with date_create or new
DateTime
Reported By: mattsch at gmail dot com
Status: Assigned
Bug Type: Feature/Change Request
Operating System: Gentoo Linux 2007.0
PHP Version: 5.2.3
Assigned To: derick
New Comment:
I have discovered that it is also unable to create years between
and 0099.
Previous Comments:
[2007-06-28 18:17:04] [EMAIL PROTECTED]
The current code was not meant to do this, so it's not a real bug -
however, I'll check whether we can support this without breaking
something else.
[2007-06-28 16:36:44] mattsch at gmail dot com
Description:
When attempting to create a new date with a negative year and display
that date, the format function returns today's date with the timezone
offset modified and set to what the negative year should be.
Reproduce code:
---
?
$date = new DateTime('-2007-06-28');
echo $date-format(DATE_ISO8601);
?
Expected result:
Output:
-2007-06-28T11:31:19-0500
Actual result:
--
Outputs:
2007-06-28T11:31:19-2007
--
Edit this bug report at http://bugs.php.net/?id=41842edit=1
#41842 [NEW]: Cannot create negative years with date_create or new DateTime
From: mattsch at gmail dot com
Operating system: Gentoo Linux 2007.0
PHP version: 5.2.3
PHP Bug Type: Date/time related
Bug description: Cannot create negative years with date_create or new DateTime
Description:
When attempting to create a new date with a negative year and display that
date, the format function returns today's date with the timezone offset
modified and set to what the negative year should be.
Reproduce code:
---
?
$date = new DateTime('-2007-06-28');
echo $date-format(DATE_ISO8601);
?
Expected result:
Output:
-2007-06-28T11:31:19-0500
Actual result:
--
Outputs:
2007-06-28T11:31:19-2007
--
Edit bug report at http://bugs.php.net/?id=41842edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41842r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41842r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41842r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41842r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41842r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41842r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41842r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41842r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41842r=support
Expected behavior:http://bugs.php.net/fix.php?id=41842r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41842r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41842r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41842r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41842r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41842r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41842r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41842r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41842r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41842r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41842r=mysqlcfg
#41844 [NEW]: Format returns incorrect number of digits for negative years -0001 to -0999
From: mattsch at gmail dot com
Operating system: Gentoo Linux 2007.0
PHP version: 5.2.3
PHP Bug Type: Date/time related
Bug description: Format returns incorrect number of digits for negative years
-0001 to -0999
Description:
Format returns incorrect number of digits for negative years -0001 to
-0999. See ISO 8601:2004 and http://en.wikipedia.org/wiki/Year_zero:
The basic format for year 0 is the four-digit form , which equals
the historical year 1 BC. Several expanded formats are possible: -
and +, as well as five- and six-digit versions. Earlier years are also
negative four-, five- or six-digit years, which have an absolute value one
less than the equivalent BC year, hence -0001 = 2 BC.
Reproduce code:
---
?
$date = new DateTime('2007-06-28');
$date-modify('-3006 years');
echo $date-format(DATE_ISO8601);
?
Outputs:
-999-06-17T00:00:00-0600
Expected:
-0999-06-17T00:00:00-0600
?
$date = new DateTime('2007-06-28');
$date-modify('-2008 years');
echo $date-format(DATE_ISO8601);
?
Outputs:
-001-06-17T00:00:00-0600
Expected:
-0001-06-17T00:00:00-0600
--
Edit bug report at http://bugs.php.net/?id=41844edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41844r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41844r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41844r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41844r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41844r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41844r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41844r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41844r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41844r=support
Expected behavior:http://bugs.php.net/fix.php?id=41844r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41844r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41844r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41844r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41844r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41844r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41844r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41844r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41844r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41844r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41844r=mysqlcfg
#41844 [Opn]: Format returns incorrect number of digits for negative years -0001 to -0999
ID: 41844
User updated by: mattsch at gmail dot com
Reported By: mattsch at gmail dot com
Status: Open
Bug Type: Date/time related
Operating System: Gentoo Linux 2007.0
PHP Version: 5.2.3
New Comment:
I didn't mean to link the colon:
http://en.wikipedia.org/wiki/Year_zero
Previous Comments:
[2007-06-28 17:30:18] mattsch at gmail dot com
Description:
Format returns incorrect number of digits for negative years -0001 to
-0999. See ISO 8601:2004 and http://en.wikipedia.org/wiki/Year_zero:
The basic format for year 0 is the four-digit form , which equals
the historical year 1 BC. Several expanded formats are possible: -
and +, as well as five- and six-digit versions. Earlier years are
also negative four-, five- or six-digit years, which have an absolute
value one less than the equivalent BC year, hence -0001 = 2 BC.
Reproduce code:
---
?
$date = new DateTime('2007-06-28');
$date-modify('-3006 years');
echo $date-format(DATE_ISO8601);
?
Outputs:
-999-06-17T00:00:00-0600
Expected:
-0999-06-17T00:00:00-0600
?
$date = new DateTime('2007-06-28');
$date-modify('-2008 years');
echo $date-format(DATE_ISO8601);
?
Outputs:
-001-06-17T00:00:00-0600
Expected:
-0001-06-17T00:00:00-0600
--
Edit this bug report at http://bugs.php.net/?id=41844edit=1
#40107 [NEW]: preg_grep should capture subpatterns
From: mattsch at gmail dot com
Operating system: *
PHP version: 5.2.0
PHP Bug Type: Feature/Change Request
Bug description: preg_grep should capture subpatterns
Description:
preg_grep should capture subpatterns. Currently it doesn't have the
ability to do this.
Reproduce code:
---
array preg_grep ( string pattern, array input [, int flags] )
Expected result:
The return array would return a two dimensional array if you set a flag
like PREG_GREP_CAPTURE. $array[n][0] would be the fully captured string
and each additional index in that dimension would return the subpattern
matches.
Example:
?php
$arrInput = array('5741234-5671','5741235','5741236-432');
$arrMatches = preg_grep('/([2-9][0-9]{6,15})(?:\-([0-9]{2,6}))?/',
$arrInput, PREG_GREP_CAPTURE);
?
Content of $arrMatches:
$arrMatches[0][0] = '5741234-5671'
$arrMatches[0][1] = '5741234'
$arrMatches[0][2] = '5671'
$arrMatches[1][0] = '5741235'
$arrMatches[2][0] = '5741236-432'
$arrMatches[2][1] = '5741236'
$arrMatches[2][2] = '432'
Actual result:
--
array preg_grep ( string pattern, array input [, int flags] )
--
Edit bug report at http://bugs.php.net/?id=40107edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40107r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40107r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40107r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40107r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40107r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40107r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40107r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40107r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40107r=support
Expected behavior:http://bugs.php.net/fix.php?id=40107r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40107r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40107r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40107r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40107r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40107r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40107r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40107r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40107r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40107r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40107r=mysqlcfg
#37210 [NEW]: array_multisort reports inconsistent warning when arrays are consistent
From: mattsch at gmail dot com Operating system: Linux PHP version: 5.1.2 PHP Bug Type: Arrays related Bug description: array_multisort reports inconsistent warning when arrays are consistent Description: array_multisort reports this warning on arrays in which the sizes are consistent: Warning: array_multisort() [function.array-multisort]: Array sizes are inconsistent in /home/www/rootsite_staging/reports/index.php on line Reproduce code: --- ?php $selectedReports = array ( 'file' = array ( 0 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060417_DAY.xls', 1 = '/home/www/staging/reports/Daily Reports/Payroll/2006/04_April2006/20060417_DailyPayroll.xls', 2 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060418_DAY.xls', 3 = '/home/www/staging/reports/Daily Reports/Payroll/2006/04_April2006/20060418_DailyPayroll.xls', 4 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060419_DAY.xls', 5 = '/home/www/staging/reports/Daily Reports/Payroll/2006/04_April2006/20060419_DailyPayroll.xls', 6 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060420_DAY.xls', 7 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060420_DAY_r1.xls', 8 = '/home/www/staging/reports/Daily Reports/Payroll/2006/04_April2006/20060420_DailyPayroll.xls', 9 = '/home/www/staging/reports/Daily Reports/Payroll/2006/04_April2006/20060420_DailyPayroll_r1.xls', 10 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060421_DAY.xls', ), 'date' = array ( 0 = '2006-04-17', 1 = '2006-04-17', 2 = '2006-04-18', 3 = '2006-04-18', 4 = '2006-04-19', 5 = '2006-04-19', 6 = '2006-04-20', 7 = '2006-04-20', 8 = '2006-04-20', 9 = '2006-04-20', 10 = '2006-04-21', ), 'revision' = array ( 0 = 0, 1 = 0, 2 = 0, 3 = 0, 4 = 0, 5 = 0, 6 = 0, 7 = 1, 8 = 0, 9 = 1, 10 = 0, ), 'report' = array ( 0 = 'Daily Manager Report', 1 = 'Payroll Report', 2 = 'Daily Manager Report', 3 = 'Payroll Report', 4 = 'Daily Manager Report', 5 = 'Payroll Report', 6 = 'Daily Manager Report', 7 = 'Daily Manager Report', 8 = 'Payroll Report', 9 = 'Payroll Report', 10 = 'Daily Manager Report', ), ); array_multisort($selectedReports['date'], $selectedReports['report'], $selectedReports['revision'], SORT_DESC, $selectedReports['file'], $selectedReports); ? Expected result: The size of each dimension dimension being sorted are consistent. I've checked it and rechecked it and even looped over it (no index error). It should not report an inconsistent warning. Actual result: -- Does not sort and reports an inconsistent size warning. -- Edit bug report at http://bugs.php.net/?id=37210edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37210r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37210r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37210r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37210r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37210r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37210r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37210r=needscript Try newer version:http://bugs.php.net/fix.php?id=37210r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37210r=support Expected behavior:http://bugs.php.net/fix.php?id=37210r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37210r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37210r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37210r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37210r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37210r=dst IIS Stability:http://bugs.php.net/fix.php?id=37210r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37210r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37210r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37210r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37210r=mysqlcfg
#37210 [Opn-Bgs]: array_multisort reports inconsistent warning when arrays are consistent
ID: 37210 User updated by: mattsch at gmail dot com Reported By: mattsch at gmail dot com -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Linux PHP Version: 5.1.2 New Comment: Sorry, this is bogus. I know what I'm doing wrong. Previous Comments: [2006-04-26 16:39:45] mattsch at gmail dot com Description: array_multisort reports this warning on arrays in which the sizes are consistent: Warning: array_multisort() [function.array-multisort]: Array sizes are inconsistent in /home/www/rootsite_staging/reports/index.php on line Reproduce code: --- ?php $selectedReports = array ( 'file' = array ( 0 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060417_DAY.xls', 1 = '/home/www/staging/reports/Daily Reports/Payroll/2006/04_April2006/20060417_DailyPayroll.xls', 2 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060418_DAY.xls', 3 = '/home/www/staging/reports/Daily Reports/Payroll/2006/04_April2006/20060418_DailyPayroll.xls', 4 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060419_DAY.xls', 5 = '/home/www/staging/reports/Daily Reports/Payroll/2006/04_April2006/20060419_DailyPayroll.xls', 6 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060420_DAY.xls', 7 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060420_DAY_r1.xls', 8 = '/home/www/staging/reports/Daily Reports/Payroll/2006/04_April2006/20060420_DailyPayroll.xls', 9 = '/home/www/staging/reports/Daily Reports/Payroll/2006/04_April2006/20060420_DailyPayroll_r1.xls', 10 = '/home/www/staging/reports/Daily Reports/DMR/2006/04_April2006/20060421_DAY.xls', ), 'date' = array ( 0 = '2006-04-17', 1 = '2006-04-17', 2 = '2006-04-18', 3 = '2006-04-18', 4 = '2006-04-19', 5 = '2006-04-19', 6 = '2006-04-20', 7 = '2006-04-20', 8 = '2006-04-20', 9 = '2006-04-20', 10 = '2006-04-21', ), 'revision' = array ( 0 = 0, 1 = 0, 2 = 0, 3 = 0, 4 = 0, 5 = 0, 6 = 0, 7 = 1, 8 = 0, 9 = 1, 10 = 0, ), 'report' = array ( 0 = 'Daily Manager Report', 1 = 'Payroll Report', 2 = 'Daily Manager Report', 3 = 'Payroll Report', 4 = 'Daily Manager Report', 5 = 'Payroll Report', 6 = 'Daily Manager Report', 7 = 'Daily Manager Report', 8 = 'Payroll Report', 9 = 'Payroll Report', 10 = 'Daily Manager Report', ), ); array_multisort($selectedReports['date'], $selectedReports['report'], $selectedReports['revision'], SORT_DESC, $selectedReports['file'], $selectedReports); ? Expected result: The size of each dimension dimension being sorted are consistent. I've checked it and rechecked it and even looped over it (no index error). It should not report an inconsistent warning. Actual result: -- Does not sort and reports an inconsistent size warning. -- Edit this bug report at http://bugs.php.net/?id=37210edit=1
#36004 [NEW]: phpinfo/php -i not outputing and/or showing errors
From: mattsch at gmail dot com Operating system: Gentoo PHP version: 5.1.2 PHP Bug Type: PHP options/info functions Bug description: phpinfo/php -i not outputing and/or showing errors Description: This produces no output in the browser: ?php phpinfo(); ? This executes only partially and stopping with an error in the shell: php -i Output right before it fails is: imagick ImageMagick support = enabled Magick Backend = ImageMagick ImageMagick version = 6.2.5 PHP imagick version = 0.9.11 MaxRGB = 65535 Supported image formats = clipmask *** glibc detected *** free(): invalid pointer: 0xbfdd7378 *** Aborted Reproduce code: --- Template: ?php phpinfo(); ? Shell: php -i Expected result: phpinfo and php -i should output and execute without errors respectively. Actual result: -- phpinfo does not output. php -i executes and stops with errors. -- Edit bug report at http://bugs.php.net/?id=36004edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36004r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36004r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36004r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36004r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36004r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36004r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36004r=needscript Try newer version:http://bugs.php.net/fix.php?id=36004r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36004r=support Expected behavior:http://bugs.php.net/fix.php?id=36004r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36004r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36004r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36004r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36004r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36004r=dst IIS Stability:http://bugs.php.net/fix.php?id=36004r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36004r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36004r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36004r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36004r=mysqlcfg
#36004 [Fbk-Opn]: phpinfo/php -i not outputing and/or showing errors
ID: 36004 User updated by: mattsch at gmail dot com Reported By: mattsch at gmail dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Gentoo PHP Version: 5.1.2 New Comment: I was thinking that might have been the problem by reading the output. I recompiled without imagick and it works fine now. I guess imagick is so antiquated now that it shouldn't be used anymore and magickwand should be used instead (which compiles fine). Should I submit a bug on PECL imagick or does it even matter? Previous Comments: [2006-01-13 21:13:00] [EMAIL PROTECTED] Does it work without imagick extension? [2006-01-13 21:04:09] mattsch at gmail dot com Description: This produces no output in the browser: ?php phpinfo(); ? This executes only partially and stopping with an error in the shell: php -i Output right before it fails is: imagick ImageMagick support = enabled Magick Backend = ImageMagick ImageMagick version = 6.2.5 PHP imagick version = 0.9.11 MaxRGB = 65535 Supported image formats = clipmask *** glibc detected *** free(): invalid pointer: 0xbfdd7378 *** Aborted Reproduce code: --- Template: ?php phpinfo(); ? Shell: php -i Expected result: phpinfo and php -i should output and execute without errors respectively. Actual result: -- phpinfo does not output. php -i executes and stops with errors. -- Edit this bug report at http://bugs.php.net/?id=36004edit=1
#35887 [Asn]: wddx_deserialize not parsing dateTime fields properly
ID: 35887 User updated by: mattsch at gmail dot com Reported By: mattsch at gmail dot com Status: Assigned Bug Type: Feature/Change Request Operating System: Gentoo PHP Version: 5.1.1 Assigned To: derick New Comment: I also looked at ISO 8601 and even previous versions because the DTD was written in 1999, but I couldn't find any mention of truncating leading zeros in the standard despite the fact that the wddx DTD says it's possible. Thanks for implementing a patch to keep compatibility nevertheless. Previous Comments: [2006-01-04 09:41:01] [EMAIL PROTECTED] I did some investigations. http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt states (written by allaire, which was bought by macromedia): Date-time values are encoded according to the full form of ISO8601, e.g., 1998-9-15T09:05:32+4:0. All documents on ISO8601 (including the standard) only give this format: -MM-DD or MMDD Single digits are not allowed. So the WDDX DTD is flawed itself, it doesn't do what it says it does (ie. They say they use full ISO8601, but they don't). I find that incredible stupid. I am marking this as a feature request for now, I do have a patch but I want to see its performance impacts on the parser first before committing it. It might not make it into PHP 5.1.2. [2006-01-04 03:04:10] mattsch at gmail dot com Here's the code from this link: http://www.silvertoncasino.com/events/titles.cfm cfsilent cfquery name=getTitles datasource=#request.dsn# SELECT startDate, eventID, (SELECT categoryID FROM categories WHERE cLink LIKE '/events/content%' LIMIT 0, 1) AS categoryID FROM events WHERE display = 1 AND endDate = '#LSDateFormat(Now(), -mm-dd)#' ORDER BY startDate, eventOrder /cfquery cfwddx action=cfml2wddx input=#getTitles# output=wddxXML /cfsilentcfheader name=Content-Type value=text/xml;charset=utf-8?xml version=1.0 encoding=UTF-8? cfoutput#wddxXML#/cfoutput You'll notice that Coldfusion produces the output using the cfwddx tag. So you will be breaking compatibility with Coldfusion wddx when you don't fix this bug. [2006-01-04 02:54:49] mattsch at gmail dot com At the very least since you guys seem willing to break backwards compatibility, make a note of it in the PHP docs that as of PHP 5.1.1, wddx dateTimes serialized with coldfusion will no longer be deserialized into unix timestamps as they previously were under PHP 5.0.4. [2006-01-04 02:51:28] mattsch at gmail dot com Again this is not bogus. Coldfusion does not output leading zeros. PHP 5.0.4 runs this code fine. On PHP 5.1.1, I get notices because it no longer parses the dateTime into a unix timestamp. Why is it so hard to fix this bug and make it work like it did in PHP 5.0.4? On the wddx DTD, it makes this statement: Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed. [2006-01-04 01:47:05] [EMAIL PROTECTED] From: http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt . . dateTime1998-06-12T04:32:12/dateTime . . Which is the one PHP works fine with. (Even PHP 4.3.11 worked) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35887 -- Edit this bug report at http://bugs.php.net/?id=35887edit=1
#35887 [NEW]: wddx_deserialize not parsing dateTime fields properly
From: mattsch at gmail dot com Operating system: Gentoo PHP version: 5.1.1 PHP Bug Type: WDDX related Bug description: wddx_deserialize not parsing dateTime fields properly Description: wddx_deserialize does not parse the dateTime like it did in php 5.0.4. 5.0.4 parsed the dateTime into a unix timestamp. 5.1.1 does not convert it and keeps it as this format: 2006-1-6T0:0:0-8:0 Reproduce code: --- $eventsXML = wddx_deserialize(file_get_contents($eventsXMLFile)); echo $eventsXML['eventDate'][$i]; Expected result: Output a unix time stamp like php 5.0.4. 5.0.4 format: 1136534400 5.1.1 format: 2006-1-6T0:0:0-8:0 Actual result: -- Outputs incorrect format for datetimes: 2006-1-6T0:0:0-8:0 -- Edit bug report at http://bugs.php.net/?id=35887edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35887r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35887r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35887r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35887r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35887r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35887r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35887r=needscript Try newer version:http://bugs.php.net/fix.php?id=35887r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35887r=support Expected behavior:http://bugs.php.net/fix.php?id=35887r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35887r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35887r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35887r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35887r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35887r=dst IIS Stability:http://bugs.php.net/fix.php?id=35887r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35887r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35887r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35887r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35887r=mysqlcfg
#35887 [Fbk-Opn]: wddx_deserialize not parsing dateTime fields properly
ID: 35887 User updated by: mattsch at gmail dot com Reported By: mattsch at gmail dot com -Status: Feedback +Status: Open Bug Type: WDDX related Operating System: Gentoo PHP Version: 5.1.1 New Comment: On php 5.0.4 this script outputs: 1136534400 On php 5.1.1 this script outputs: 2006-1-6T0:0:0-8:0 ?php $eventsXML = wddxPacket version='1.0'header/datarecordset rowCount='1' fieldNames='eventDate' type='coldfusion.sql.QueryTable'field name='eventDate'dateTime2006-1-6T0:0:0-8:0/dateTime/field/recordset/data/wddxPacket; $eventsXML = wddx_deserialize($eventsXML); echo $eventsXML['eventDate'][0]; ? Previous Comments: [2006-01-03 21:31:37] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Without external files please... [2006-01-03 21:27:59] mattsch at gmail dot com Description: wddx_deserialize does not parse the dateTime like it did in php 5.0.4. 5.0.4 parsed the dateTime into a unix timestamp. 5.1.1 does not convert it and keeps it as this format: 2006-1-6T0:0:0-8:0 Reproduce code: --- $eventsXML = wddx_deserialize(file_get_contents($eventsXMLFile)); echo $eventsXML['eventDate'][$i]; Expected result: Output a unix time stamp like php 5.0.4. 5.0.4 format: 1136534400 5.1.1 format: 2006-1-6T0:0:0-8:0 Actual result: -- Outputs incorrect format for datetimes: 2006-1-6T0:0:0-8:0 -- Edit this bug report at http://bugs.php.net/?id=35887edit=1
#35887 [Bgs-Opn]: wddx_deserialize not parsing dateTime fields properly
ID: 35887 User updated by: mattsch at gmail dot com Reported By: mattsch at gmail dot com -Status: Bogus +Status: Open Bug Type: WDDX related Operating System: Gentoo PHP Version: 5.1.1 New Comment: This not bogus! PHP 5.0.4 parses this date. It doesn't matter if it's not the proper iso format. Allaire made wddx in Coldfusion and it has been outputting dates in that format since day 1. Take a look at this link which is what coldfusion wddx outputs: http://www.silvertoncasino.com/events/titles.cfm (This server is running Coldfusion MX 6.1) Previous Comments: [2006-01-03 23:43:24] [EMAIL PROTECTED] 2006-1-6T0:0:0-8:0 is not a valid wddx format (which follows ISO8601, http://www.cl.cam.ac.uk/~mgk25/iso-time.html) [2006-01-03 23:12:21] mattsch at gmail dot com On php 5.0.4 this script outputs: 1136534400 On php 5.1.1 this script outputs: 2006-1-6T0:0:0-8:0 ?php $eventsXML = wddxPacket version='1.0'header/datarecordset rowCount='1' fieldNames='eventDate' type='coldfusion.sql.QueryTable'field name='eventDate'dateTime2006-1-6T0:0:0-8:0/dateTime/field/recordset/data/wddxPacket; $eventsXML = wddx_deserialize($eventsXML); echo $eventsXML['eventDate'][0]; ? [2006-01-03 21:31:37] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Without external files please... [2006-01-03 21:27:59] mattsch at gmail dot com Description: wddx_deserialize does not parse the dateTime like it did in php 5.0.4. 5.0.4 parsed the dateTime into a unix timestamp. 5.1.1 does not convert it and keeps it as this format: 2006-1-6T0:0:0-8:0 Reproduce code: --- $eventsXML = wddx_deserialize(file_get_contents($eventsXMLFile)); echo $eventsXML['eventDate'][$i]; Expected result: Output a unix time stamp like php 5.0.4. 5.0.4 format: 1136534400 5.1.1 format: 2006-1-6T0:0:0-8:0 Actual result: -- Outputs incorrect format for datetimes: 2006-1-6T0:0:0-8:0 -- Edit this bug report at http://bugs.php.net/?id=35887edit=1
#35887 [Opn]: wddx_deserialize not parsing dateTime fields properly
ID: 35887 User updated by: mattsch at gmail dot com Reported By: mattsch at gmail dot com Status: Open Bug Type: WDDX related Operating System: Gentoo PHP Version: 5.1.1 New Comment: Taken from http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt: Date-time values- Date-time values are encoded according to the full form of ISO8601, e.g., 1998-9-15T09:05:32+4:0. Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed. While timezone information is optional, it must be successfully parsed and used to convert to local date-time values. Efforts should me made to ensure that the internal representation of date-time values does not suffer from Y2K problems and covers a sufficient range of dates. In particular, years must always be represented with four digits. Previous Comments: [2006-01-03 23:53:56] mattsch at gmail dot com This not bogus! PHP 5.0.4 parses this date. It doesn't matter if it's not the proper iso format. Allaire made wddx in Coldfusion and it has been outputting dates in that format since day 1. Take a look at this link which is what coldfusion wddx outputs: http://www.silvertoncasino.com/events/titles.cfm (This server is running Coldfusion MX 6.1) [2006-01-03 23:43:24] [EMAIL PROTECTED] 2006-1-6T0:0:0-8:0 is not a valid wddx format (which follows ISO8601, http://www.cl.cam.ac.uk/~mgk25/iso-time.html) [2006-01-03 23:12:21] mattsch at gmail dot com On php 5.0.4 this script outputs: 1136534400 On php 5.1.1 this script outputs: 2006-1-6T0:0:0-8:0 ?php $eventsXML = wddxPacket version='1.0'header/datarecordset rowCount='1' fieldNames='eventDate' type='coldfusion.sql.QueryTable'field name='eventDate'dateTime2006-1-6T0:0:0-8:0/dateTime/field/recordset/data/wddxPacket; $eventsXML = wddx_deserialize($eventsXML); echo $eventsXML['eventDate'][0]; ? [2006-01-03 21:31:37] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Without external files please... [2006-01-03 21:27:59] mattsch at gmail dot com Description: wddx_deserialize does not parse the dateTime like it did in php 5.0.4. 5.0.4 parsed the dateTime into a unix timestamp. 5.1.1 does not convert it and keeps it as this format: 2006-1-6T0:0:0-8:0 Reproduce code: --- $eventsXML = wddx_deserialize(file_get_contents($eventsXMLFile)); echo $eventsXML['eventDate'][$i]; Expected result: Output a unix time stamp like php 5.0.4. 5.0.4 format: 1136534400 5.1.1 format: 2006-1-6T0:0:0-8:0 Actual result: -- Outputs incorrect format for datetimes: 2006-1-6T0:0:0-8:0 -- Edit this bug report at http://bugs.php.net/?id=35887edit=1
#35887 [Opn]: wddx_deserialize not parsing dateTime fields properly
ID: 35887 User updated by: mattsch at gmail dot com Reported By: mattsch at gmail dot com Status: Open Bug Type: WDDX related Operating System: Gentoo PHP Version: 5.1.1 New Comment: Also note under Time zone processing: http://livedocs.macromedia.com/coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/XML11.htm Date-time values in WDDX are represented using a subset of the ISO8601 format. Time zone information is represented as an hour/minute offset from Coordinated Universal Time (UTC); for example, 2002-9-8T12:6:26-4:0. Previous Comments: [2006-01-04 00:04:48] mattsch at gmail dot com Taken from http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt: Date-time values- Date-time values are encoded according to the full form of ISO8601, e.g., 1998-9-15T09:05:32+4:0. Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed. While timezone information is optional, it must be successfully parsed and used to convert to local date-time values. Efforts should me made to ensure that the internal representation of date-time values does not suffer from Y2K problems and covers a sufficient range of dates. In particular, years must always be represented with four digits. [2006-01-03 23:53:56] mattsch at gmail dot com This not bogus! PHP 5.0.4 parses this date. It doesn't matter if it's not the proper iso format. Allaire made wddx in Coldfusion and it has been outputting dates in that format since day 1. Take a look at this link which is what coldfusion wddx outputs: http://www.silvertoncasino.com/events/titles.cfm (This server is running Coldfusion MX 6.1) [2006-01-03 23:43:24] [EMAIL PROTECTED] 2006-1-6T0:0:0-8:0 is not a valid wddx format (which follows ISO8601, http://www.cl.cam.ac.uk/~mgk25/iso-time.html) [2006-01-03 23:12:21] mattsch at gmail dot com On php 5.0.4 this script outputs: 1136534400 On php 5.1.1 this script outputs: 2006-1-6T0:0:0-8:0 ?php $eventsXML = wddxPacket version='1.0'header/datarecordset rowCount='1' fieldNames='eventDate' type='coldfusion.sql.QueryTable'field name='eventDate'dateTime2006-1-6T0:0:0-8:0/dateTime/field/recordset/data/wddxPacket; $eventsXML = wddx_deserialize($eventsXML); echo $eventsXML['eventDate'][0]; ? [2006-01-03 21:31:37] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Without external files please... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35887 -- Edit this bug report at http://bugs.php.net/?id=35887edit=1
#35887 [Bgs-Opn]: wddx_deserialize not parsing dateTime fields properly
ID: 35887 User updated by: mattsch at gmail dot com Reported By: mattsch at gmail dot com -Status: Bogus +Status: Open Bug Type: WDDX related Operating System: Gentoo PHP Version: 5.1.1 New Comment: Again this is not bogus. Coldfusion does not output leading zeros. PHP 5.0.4 runs this code fine. On PHP 5.1.1, I get notices because it no longer parses the dateTime into a unix timestamp. Why is it so hard to fix this bug and make it work like it did in PHP 5.0.4? On the wddx DTD, it makes this statement: Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed. Previous Comments: [2006-01-04 01:47:05] [EMAIL PROTECTED] From: http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt . . dateTime1998-06-12T04:32:12/dateTime . . Which is the one PHP works fine with. (Even PHP 4.3.11 worked) [2006-01-04 00:48:49] mattsch at gmail dot com Also note under Time zone processing: http://livedocs.macromedia.com/coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/XML11.htm Date-time values in WDDX are represented using a subset of the ISO8601 format. Time zone information is represented as an hour/minute offset from Coordinated Universal Time (UTC); for example, 2002-9-8T12:6:26-4:0. [2006-01-04 00:04:48] mattsch at gmail dot com Taken from http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt: Date-time values- Date-time values are encoded according to the full form of ISO8601, e.g., 1998-9-15T09:05:32+4:0. Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed. While timezone information is optional, it must be successfully parsed and used to convert to local date-time values. Efforts should me made to ensure that the internal representation of date-time values does not suffer from Y2K problems and covers a sufficient range of dates. In particular, years must always be represented with four digits. [2006-01-03 23:53:56] mattsch at gmail dot com This not bogus! PHP 5.0.4 parses this date. It doesn't matter if it's not the proper iso format. Allaire made wddx in Coldfusion and it has been outputting dates in that format since day 1. Take a look at this link which is what coldfusion wddx outputs: http://www.silvertoncasino.com/events/titles.cfm (This server is running Coldfusion MX 6.1) [2006-01-03 23:43:24] [EMAIL PROTECTED] 2006-1-6T0:0:0-8:0 is not a valid wddx format (which follows ISO8601, http://www.cl.cam.ac.uk/~mgk25/iso-time.html) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35887 -- Edit this bug report at http://bugs.php.net/?id=35887edit=1
#35887 [Opn]: wddx_deserialize not parsing dateTime fields properly
ID: 35887 User updated by: mattsch at gmail dot com Reported By: mattsch at gmail dot com Status: Open Bug Type: WDDX related Operating System: Gentoo PHP Version: 5.1.1 New Comment: At the very least since you guys seem willing to break backwards compatibility, make a note of it in the PHP docs that as of PHP 5.1.1, wddx dateTimes serialized with coldfusion will no longer be deserialized into unix timestamps as they previously were under PHP 5.0.4. Previous Comments: [2006-01-04 02:51:28] mattsch at gmail dot com Again this is not bogus. Coldfusion does not output leading zeros. PHP 5.0.4 runs this code fine. On PHP 5.1.1, I get notices because it no longer parses the dateTime into a unix timestamp. Why is it so hard to fix this bug and make it work like it did in PHP 5.0.4? On the wddx DTD, it makes this statement: Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed. [2006-01-04 01:47:05] [EMAIL PROTECTED] From: http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt . . dateTime1998-06-12T04:32:12/dateTime . . Which is the one PHP works fine with. (Even PHP 4.3.11 worked) [2006-01-04 00:48:49] mattsch at gmail dot com Also note under Time zone processing: http://livedocs.macromedia.com/coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/XML11.htm Date-time values in WDDX are represented using a subset of the ISO8601 format. Time zone information is represented as an hour/minute offset from Coordinated Universal Time (UTC); for example, 2002-9-8T12:6:26-4:0. [2006-01-04 00:04:48] mattsch at gmail dot com Taken from http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt: Date-time values- Date-time values are encoded according to the full form of ISO8601, e.g., 1998-9-15T09:05:32+4:0. Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed. While timezone information is optional, it must be successfully parsed and used to convert to local date-time values. Efforts should me made to ensure that the internal representation of date-time values does not suffer from Y2K problems and covers a sufficient range of dates. In particular, years must always be represented with four digits. [2006-01-03 23:53:56] mattsch at gmail dot com This not bogus! PHP 5.0.4 parses this date. It doesn't matter if it's not the proper iso format. Allaire made wddx in Coldfusion and it has been outputting dates in that format since day 1. Take a look at this link which is what coldfusion wddx outputs: http://www.silvertoncasino.com/events/titles.cfm (This server is running Coldfusion MX 6.1) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35887 -- Edit this bug report at http://bugs.php.net/?id=35887edit=1
#35887 [Opn]: wddx_deserialize not parsing dateTime fields properly
ID: 35887 User updated by: mattsch at gmail dot com Reported By: mattsch at gmail dot com Status: Open Bug Type: WDDX related Operating System: Gentoo PHP Version: 5.1.1 New Comment: Here's the code from this link: http://www.silvertoncasino.com/events/titles.cfm cfsilent cfquery name=getTitles datasource=#request.dsn# SELECT startDate, eventID, (SELECT categoryID FROM categories WHERE cLink LIKE '/events/content%' LIMIT 0, 1) AS categoryID FROM events WHERE display = 1 AND endDate = '#LSDateFormat(Now(), -mm-dd)#' ORDER BY startDate, eventOrder /cfquery cfwddx action=cfml2wddx input=#getTitles# output=wddxXML /cfsilentcfheader name=Content-Type value=text/xml;charset=utf-8?xml version=1.0 encoding=UTF-8? cfoutput#wddxXML#/cfoutput You'll notice that Coldfusion produces the output using the cfwddx tag. So you will be breaking compatibility with Coldfusion wddx when you don't fix this bug. Previous Comments: [2006-01-04 02:54:49] mattsch at gmail dot com At the very least since you guys seem willing to break backwards compatibility, make a note of it in the PHP docs that as of PHP 5.1.1, wddx dateTimes serialized with coldfusion will no longer be deserialized into unix timestamps as they previously were under PHP 5.0.4. [2006-01-04 02:51:28] mattsch at gmail dot com Again this is not bogus. Coldfusion does not output leading zeros. PHP 5.0.4 runs this code fine. On PHP 5.1.1, I get notices because it no longer parses the dateTime into a unix timestamp. Why is it so hard to fix this bug and make it work like it did in PHP 5.0.4? On the wddx DTD, it makes this statement: Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed. [2006-01-04 01:47:05] [EMAIL PROTECTED] From: http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt . . dateTime1998-06-12T04:32:12/dateTime . . Which is the one PHP works fine with. (Even PHP 4.3.11 worked) [2006-01-04 00:48:49] mattsch at gmail dot com Also note under Time zone processing: http://livedocs.macromedia.com/coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/XML11.htm Date-time values in WDDX are represented using a subset of the ISO8601 format. Time zone information is represented as an hour/minute offset from Coordinated Universal Time (UTC); for example, 2002-9-8T12:6:26-4:0. [2006-01-04 00:04:48] mattsch at gmail dot com Taken from http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt: Date-time values- Date-time values are encoded according to the full form of ISO8601, e.g., 1998-9-15T09:05:32+4:0. Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed. While timezone information is optional, it must be successfully parsed and used to convert to local date-time values. Efforts should me made to ensure that the internal representation of date-time values does not suffer from Y2K problems and covers a sufficient range of dates. In particular, years must always be represented with four digits. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35887 -- Edit this bug report at http://bugs.php.net/?id=35887edit=1
