use SecurityContextInterface instead of SecurityContext
[TwigBundle] Workaround a flaw in the design of the configuration (normalization)
fixed timezone bug in DateTimeToTimestampTransformer
merged branch Spea/2.0 (PR #3590)

Commits
-------

50cb486 Fixed proxy generation in the DoctrineBundle when using Doctrine >= 2.2.0

Discussion
----------

[DoctrineBundle] Fixed proxy generation with Doctrine >= 2.2.0

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes

The issue here was, that the name of the generated Proxy files have changed in Doctrine 2.2.0, thus the autoloader in the DoctrineBundle stoped working.

This PR fixes this issue by applying different string manipulations to the given class name depending on the currently used Doctrine version.

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

by fabpot at 2012-03-14T07:13:23Z

Can you squash your commits before I merge? Thanks.

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

by Spea at 2012-03-14T09:33:10Z

Should I open a new PR when squashed the commits? Because I don't know what happens when I force the remote repository to push my squashed commits.

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

by stloyd at 2012-03-14T09:48:05Z

First you should rebase (normally), then squash and push with `--force`, then GH will automaticaly update this PR (if you push into same branch on which bases this PR).

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

by Spea at 2012-03-14T10:04:30Z

Yeah I knew about the ```--force``` option. I just wasn't sure what happens when I do it. Thank you!

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

by Spea at 2012-03-14T10:14:23Z

Squashed commits.
merged branch alan0101c/datatransformer-tz-fix (PR #3589)

Commits
-------

17c3482 fixed timezone bug in DateTimeToTimestampTransformer

Discussion
----------

[FIX]fixed timezone bug in DateTimeToTimestampTransformer

After several trials, I found out that the original code

```php
$dateTime = new \DateTime(sprintf("@%s %s", $value, $this->outputTimezone));
```
would create a DateTime object with timezone being '0000', even though $this->outputTimezone is set to my local timezone.

so I expanded the code a bit and it's working now.

PHP Test code,

```PHP
$d = new DateTime("@1234567890 Asia/Tokyo");
echo date_format($d, 'Y/m/d H:i:s')."\n";
echo $d->getTimezone()->getName()."\n";

$d = new DateTime("now Asia/Hong_Kong");
echo date_format($d, 'Y/m/d H:i:s')."\n";
echo $d->getTimezone()->getName()."\n";
```

The output is as followed:
2009/02/13 23:31:30
+00:00
2012/03/13 03:35:55
Asia/Hong_Kong

This could be a bug of PHP,

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

by stealth35 at 2012-03-13T15:54:31Z

:+1:
Fixed an "Array to string conversion" warning when using PHP 5.4. Also affects Symfony2 master.
merged branch fixe/patch-3 (PR #3597)

Commits
-------

ed218bb Fixed an "Array to string conversion" warning when using PHP 5.4. Also affects Symfony2 master.

Discussion
----------

[Config] Fixed an "Array to string conversion" warning when using PHP 5.4

This also affects Symfony2 master
Revert "Throw exception when "date_widget" option is not equal to "time_widget""

This reverts commit 3c2539fccbaaded0025c96bf56b7767440b2b28f.

Conflicts:

	tests/Symfony/Tests/Component/Form/Extension/Core/Type/DateTimeTypeTest.php
merged branch xavierbriand/pr-datetime-type (PR #3604)

Commits
-------

1b395f5 Revert "Throw exception when "date_widget" option is not equal to "time_widget""

Discussion
----------

Reverts commit 3c2539 to remove exception when DateTypeType has differents date and time widgets

see https://github.com/symfony/symfony/pull/1419
merged branch vicb/twig_cfg/2.0 (PR #3545)

Commits
-------

eee5065 [TwigBundle] Workaround a flaw in the design of the configuration (normalization)

Discussion
----------

[TwigBundle] Workaround a flaw in the design of the configuration (norma...

...lization)

see #2823

@Seldaek please comment.

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

by Seldaek at 2012-03-09T20:52:47Z

It seems fine at first glance. I don't have time to look at it in detail right now sorry.
Update src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php
merged branch arnapou/2.0 (PR #3610)

Commits
-------

fbed9ff Update src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php

Discussion
----------

Branch 2.0 - Correct bad HttpCache behaviour when waiting for unlock.

I read the class Symfony\Component\HttpKernel\HttpCache\HttpCache and I found something which looks like a bug lines 518-520 (in lock method) :
$wait = 0;
while (is_file($lock) && $wait < 5000000) {
usleep($wait += 50000);
}
This code can wait at maximum 50000+100000+150000+.... 4950000 µs = more than 250 seconds !

I corrected like that :
$wait = 0;
while (is_file($lock) && $wait < 5000000) {
usleep(50000);
$wait += 50000
}

This code will wait 5 sec maximum.

This is more coherent if we read the following lines of this method.

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

by arnapou at 2012-03-15T20:09:13Z

Hope I succeded to do a correct PR.
One hour of manipulation in Github for 2 lines of code let me a bitter taste on the tongue...
I was closed to tell you "Do It Yourself" ... what a waste of time...
This interface is not obvious, even if we had already worked on svn/git on *nix.
Changed instances of \DateTimeZone::UTC to 'UTC' as the constant is not valid a produces this error when DateTimeZone is instantiated: DateTimeZone::__construct() [<a href='datetimezone.--construct'>datetimezone.--construct</a>]: Unknown or bad timezone (1024)
Webprofiler ipv6 search fix
merged branch pulzarraider/webprofiler_serch_ipv6_fix (PR #3626)

Commits
-------

54b2413 Webprofiler ipv6 search fix

Discussion
----------

[WebProfilerBundle] ipv6 search fix

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
merged branch nodrew/2.0 (PR #3625)

Commits
-------

8642473 Changed instances of \DateTimeZone::UTC to 'UTC' as the constant is not valid a produces this error when DateTimeZone is instantiated: DateTimeZone::__construct() [<a href='datetimezone.--construct'>datetimezone.--construct</a>]: Unknown or bad timezone (1024)

Discussion
----------

[Locale] DateTimeZone called incorrectly by default

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no (there were two tests that were failing previously, that still fail)
Fixes the following tickets: none
Todo: none

While running, a warning throws every single time when the code

```php
new \DateTimeZone(\DateTimeZone::UTC);
```
is encountered. It is normally caught as a thrown exception and then corrected here:

```php
// src/Symfony/Component/Locale/Stub/StubIntlDateFormatter.php:442
        try {
            $this->dateTimeZone = new \DateTimeZone($timeZoneId);
        } catch (\Exception $e) {
            $this->dateTimeZone = new \DateTimeZone('UTC');
        }
```

However in my particular infrastructure, for whatever reason in production only, it causes an error to appear on shutdown in the logs. As ultimately the constant can NEVER pass, it should not be attempted with the constant. Instead, the correct 'UTC' should be passed in (as done in the catch statement).
updated vendors for 2.0.12
updated CHANGELOG for 2.0.12
update CONTRIBUTORS for 2.0.12
updated VERSION for 2.0.12