This script reproduces it. Interestingly, this script also causes a stack smash to happen for me on Ubuntu, for which I have raised a separate bug (launchpad 239513). It runs fine under gentoo though and reproduces this bug properly.

<?php
	$params = array(new DateTime());

	print_r($params);

	echo "This is useless:\n";

	print_r(xmlrpc_encode_request('x', $params));

	echo "\nThis is what I would expect to happen automatically:\n";

	$params2 = array(new DateTime());

	$params2[0] = $params2[0]->format(DATE_ISO8601);
	xmlrpc_set_type($params2[0], 'datetime');

	print_r(xmlrpc_encode_request('x', $params2));
?>

There is no statement that we can use DateTime object for 
passing to an xmlrpc function, and actually, we can't use it.
It is a limitation of current implementation of xmlrpc extension.
However, I think we MAY support DateTime object in xmlrpc extension.

Current xmlrpc extension allows you to create xmlrpc datetime 
value from an ISO-8601 format string. So you can code like this:

<?php
$obj=new DateTime();
$datetime=$obj->format(DATE_ISO8601);
xmlrpc_set_type($datetime,'datetime');
var_dump(xmlrpc_encode_request('x',$datetime));
?>

Yes, that's kinda the point to this bug report.

When xmlrpc_encode_request walks the parameters array (recursively), any DateTime objects it encounters should be encoded as XMLRPC datetime parameters (exactly like your snippet and the latter half of my example demonstrate) transparently.

In other words, I'd expect the output from the first part of my script to be identical to the output from the second.

IMHO, this is not a bug but may be a feature request.

By the way, if we're going to support DateTime class object, 
how do you think what the result of xmlrpc_decode_request 
should be look like (keeping backword compatibility, of cource)?