Description:
------------
If you set a time zone for a DateTime via DateTime::setTimeZone() and that time zone has no ID you get an error message and the time zone will not be set.

This can lead to problems if you have two DateTime objects from a source you do not control and want to format the second DateTime object in the same time zone as the first.

Reproduce code:
---------------
$d1 = new DateTime('2008-01-01 12:00:00 +02:00');
$d2 = new DateTime('2008-01-01 12:00:00 UTC');
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;
$d2->setTimeZone($d1->getTimeZone());
echo $d1->format(DATE_ISO8601), PHP_EOL;
echo $d2->format(DATE_ISO8601), PHP_EOL;

Expected result:
----------------
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+0000
2008-01-01T12:00:00+0200
2008-01-01T14:00:00+0200

Actual result:
--------------
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+0000
PHP Warning:  DateTime::setTimezone(): Can only do this for zones with
ID for now in /Users/tobias/test.php on line 5

Warning: DateTime::setTimezone(): Can only do this for zones with ID for
now in /Users/tobias/test.php on line 5
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+0000

I was able to reproduce this with PHP 5.2.9 from the commandline. 

php -v
PHP 5.2.9 (cli) (built: May  1 2009 13:47:24) 

$> php -r '$d = new DateTime("2009-01-01 00:00:00+0400"); $d->setTimezone($d->getTimezone());'

I confirm the same on PHP 5.3.3, Debian 64bit.

Still the same in PHP 5.4.10.
This bug is more than 4 years old, could it be looked into?

I'm getting this warning when trying to set a DateTime's timezone to 
"America/Los_Angeles". I don't know what an ID is in this context, but surely 
America/Los_Angeles has one... right? I'm using PHP 5.3.21 on OSX Mountain Lion.

Great to see it fixed - but confused in which release though :/

Bug 45543 is not referenced on the changelog (http://php.net/ChangeLog-5.php) - try&error tells me that on 5.4.31 the problem's gone, while on 5.3.23 (the machine on which i just happened to see this for the first time ever) it isn't.

Judging from the latest 5.3.28 release date i reckon it's not fixed in that (?)

It would be really important to know at this point which version to jump to - this way i'm doomed to work around the error, as i'm deploying to a customers' managed server and cannot be sure which available version will fix it.

http://3v4l.org/mlZX7 indicates 5.4.26 and 5.5.10.