Handle the deprecation of IntlDateFormatter::setTimeZoneId() in PHP 5.5.

Optionally use the new IntlDateFormatter::setTimeZone() method if it exists.
Fix version_compare() calls for PHP 5.5.

Until PHP 5.5 hits beta, the version number for Git builds is still 5.5.0-dev,
which is less than 5.5.0alpha1 according to version_compare(). This means that
the branches for 5.5 aren't being executed on 5.5 snapshots at present.
[Process] In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process)
merged branch stloyd/bugfix/process_cwd (PR #6620)

This PR was merged into the 2.0 branch.

Commits
-------

880da01 [Process] In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process)

Discussion
----------

[2.0][Process] In edge cases `getcwd()` can return `false`

Bug fix: yes
Feature addition: no
BC break: no
Symfony2 tests pass: yes

In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process).

---------------------------------------------------------------------------

by stloyd at 2013-01-08T12:43:40Z

I guess that this could be related to #6496, as error code `267` at Windows means:
[`ERROR_DIRECTORY - The directory name is invalid.`](http://msdn.microsoft.com/en-us/library/ms681382%28v=vs.85%29.aspx#error_directory)

---------------------------------------------------------------------------

by Seldaek at 2013-01-08T12:57:38Z

If null already uses the current working directory, what's the point of calling getcwd() at all?

---------------------------------------------------------------------------

by stloyd at 2013-01-08T13:03:06Z

@Seldaek TBH. I don't have idea =) It seems that it's there _from the beginning_, but yeah, I was a bit confused by usage of it too...

---------------------------------------------------------------------------

by fabpot at 2013-01-09T08:13:24Z

What about removing the code altogether?

---------------------------------------------------------------------------

by stloyd at 2013-01-09T08:22:55Z

@fabpot I'm ok with that, just not sure it will not be an BC break...

---------------------------------------------------------------------------

by Seldaek at 2013-01-09T08:24:57Z

php.net says `or NULL if you want to use the default value (the working
dir of the current PHP process)` which sounds like getcwd() to me.

---------------------------------------------------------------------------

by Seldaek at 2013-01-09T08:26:32Z

For full BC though, `getWorkingDirectory` should `return $this->cwd ?:
getcwd();` Then at least if that call fails the whole process isn't
failing. I don't see why anyone would use that getter though.

---------------------------------------------------------------------------

by stloyd at 2013-01-10T12:43:59Z

@fabpot @Seldaek What do you think about this now?

---------------------------------------------------------------------------

by Seldaek at 2013-01-10T12:58:39Z

:+1:
Removed underscores from test method names to be consistent with other components.

It is more common to use fully camel-cased names for test methods. Only some of the test methods are called with underscore notation. To avoid confusion it is better to be consistent.
merged branch jakzal/no-underscored-methods-in-tests-2.1 (PR #6695)

This PR was merged into the 2.1 branch.

Commits
-------

8024262 Removed underscores from test method names to be consistent with other components.

Discussion
----------

Removed underscores from test method names to be consistent with other components

This is just a cosmetic change. It is more common (in Symfony) to use fully camel-cased names for test methods. Only some of the test methods contain underscores. To avoid confusion it is better to be consistent.

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
Fix version_compare() calls for PHP 5.5.

Until PHP 5.5 hits beta, the version number for Git builds is still 5.5.0-dev,
which is less than 5.5.0alpha1 according to version_compare(). This means that
the branches for 5.5 aren't being executed on 5.5 snapshots at present.
[Profiler] [Redis] Fix sort of profiler rows.
merged branch stephpy/redis_profiler_sort (PR #6703)

This PR was merged into the 2.1 branch.

Commits
-------

9257b03 [Profiler] [Redis] Fix sort of profiler rows.

Discussion
----------

[Profiler] [Redis] Fix sort of redis storage profiler rows.

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT

Redis profiler rows are not sorted as expected.

We have in redis:

```
- 2011-01-01 ...
- 2011-01-02 ...
- 2011-01-03 ...
```

If we limit to 2, we'll have:

```
- 2011-01-02 ...
- 2011-01-01 ...
```

Fixed this bug by reversing array.
merged branch LawnGnome/PHP-5.5-compat-2.0 (PR #6699)

This PR was merged into the 2.0 branch.

Commits
-------

c7bfce9 Fix version_compare() calls for PHP 5.5.

Discussion
----------

[2.0] [Form] [Locale] PHP 5.5 compatibility fixes

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: unknown, can't run the test suite on 2.0 due to `Doctrine\DBAL\Logging\DebugStack` not being found
Fixes the following tickets: N/A
Todo: None
License of the code: MIT
Documentation PR: N/A

A backport of #6647 to the Symfony 2.0 branch, as requested. This affects a couple of files that aren't affected on 2.1.
Merge branch '2.0' into 2.1

* 2.0:
  Fix version_compare() calls for PHP 5.5.
  [Process] In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process)

Conflicts:
	src/Symfony/Component/Form/Extension/Core/ChoiceList/MonthChoiceList.php
merged branch LawnGnome/PHP-5.5-compat (PR #6647)

This PR was merged into the 2.1 branch.

Commits
-------

4991607 Fix version_compare() calls for PHP 5.5.
34def9f Handle the deprecation of IntlDateFormatter::setTimeZoneId() in PHP 5.5.

Discussion
----------

[Form] [Locale] PHP 5.5 compatibility fixes

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: N/A
Todo: None
License of the code: MIT
Documentation PR: N/A

IntlDateFormatter::setTimeZoneId() is deprecated in PHP 5.5, which results in E_DEPRECATED errors when using the date form type. This PR works around that.

Furthermore, the version_compare() tests used in locale to detect PHP 5.5 are broken with snapshot and Git builds of PHP. I've also committed a fix for those tests in this PR.

---------------------------------------------------------------------------

by stof at 2013-01-10T08:24:15Z

shouldn't it even be done in 2.0 as it is a bugfix ?

---------------------------------------------------------------------------

by LawnGnome at 2013-01-11T00:49:11Z

Possibly — I don't know enough about Symfony's release management to know whether this is appropriate for 2.0, and I was mostly scratching my own itch, honestly.

---------------------------------------------------------------------------

by stof at 2013-01-11T01:51:35Z

well, it is a bugfix and 2.0 is also impacted, so it should be done in it.

---------------------------------------------------------------------------

by LawnGnome at 2013-01-11T02:52:21Z

The diff for 2.0 looks like it'll be just the StubIntlDateFormatter.php changes — the deprecated method isn't called in DateType on that branch, and there aren't any StubIntlDateFormatter tests on 2.0. How do you want that submitted — as a separate PR against 2.0?

---------------------------------------------------------------------------

by fabpot at 2013-01-11T07:20:18Z

@LawnGnome A separate pull request would be good. Thanks.

---------------------------------------------------------------------------

by LawnGnome at 2013-01-11T08:29:48Z

2.0 PR added as #6699.
[Console] fixed input bug when the value of an option is empty (closes #6649, closes #6689)
fixes a bug when output/error output contains a % character
[Process] Fix docblocks, remove `return` from `PhpProcess#start()` as parent returns nothing, cleaned up `ExecutableFinder`
merged branch schmittjoh/exFix (PR #6716)

This PR was merged into the 2.1 branch.

Commits
-------

785d365 fixes a bug when output/error output contains a % character

Discussion
----------

fixes a bug when output/error output contains a % character
merged branch stloyd/bugfix/process_phpdocs (PR #6626)

This PR was merged into the 2.1 branch.

Commits
-------

a62e04f [Process] Fix docblocks, remove `return` from `PhpProcess#start()` as parent returns nothing, cleaned up `ExecutableFinder`

Discussion
----------

[2.1][Process] Fix docblocks, remove `return` from `PhpProcess#start()`
fixed CS
added a way to enable/disable PHP support when parsing a YAML input via Yaml::parse()

PHP support when parsing a file has been disabled by default.
If you do need PHP support when parsing a YAML file, enable it via:

    Yaml::setPhpParsing(true);

As of Symfony 2.1, PHP support is disabled by default, and support will
be removed in Symfony 2.3.
added a way to enable/disable object support when parsing/dumping

By default, object support is disabled, and instead of throwing an
exception when an object is handled, null is returned.

If you do need object support, enable it via:

    Yaml::dump($data, false, true);

If you want an exception to be thrown in case an invalid type is handled
(a PHP resource or a PHP object), pass true as the second argument:

    Yaml::dump($data, true, true);

The same can be done when parsing:

    Yaml::parse($data, 2, false, true);