@soullivaneuh You could probably base your fix on the tests from #12843.

@xabbuh ok I will rebase my commit and run this test when it will be merged.

The options that were used need to be readded too, as it's now a bc break (throwing an option does not exist exception)

@wouterj I understand. I made this PR in priority to fix a critical error for most applications.

Don't know how @fabpot and symfony team want to manage this BC break.

Using Timezone for time doesn't make sense and leads to problems with DST (which was the original issue). So for that we can use UTC as timezone and Jan 1st, 1970 as the date (for BC).

The problem with the Date and timezone was that you could get the wrong date (for the same reason).
#7187 (comment)

Doctrine also warns for storing an timezone specific DateTime in the DB and advises to use UTC as timezone instead.

So for Date(Time) we should be able to use the timezone of the user (view) and convert it to UTC in the model.

Time is simply something we can't fix without a Date, so using UTC for BC seems like the best compromise.

Why not implement a single option to determine the timezone to use. It can be set default to null or UTC or date_default_timezone_get().

If you set the timezone to null it will use the default date_default_timezone_get().

I sugest this solution (lucagtc@0b3062f).
Use only model_timezone.

Doctrine (Propel I don't know, but it should be the same) by default create DateTime for date and time field with default timezone, so I'm suggest to leave model_timezone = null.

Luca

ping @webmozart

The problem is that Doctrine creates DateTime objects with the default timezone in the "time" type but the Form Component assumes UTC in the model, so there's a nice break here.

Even I agree that timezones make no sense in time types this is not a subtle change, it should have been done in 3.0 with some coordination with the Doctrine team.

+1 for the quick fix!

Thank you @soullivaneuh.