…zones (fancyweb)This PR was merged into the 3.4 branch.Discussion----------[Validator][ConstraintValidator] Safe fail on invalid timezonesCo-authored-by: Scott Dawson <scott@loyaltycorp.com.au>| Q             | A| ------------- | ---| Branch?       | 3.4| Bug fix?      | yes| New feature?  | no| Deprecations? | no| Tickets       |#33901| License       | MIT| Doc PR        |Alternative to#33902.I will explain why I think it is better this way:1. We set the timezone with the setter because it's 100% safe, it never fails. It fall backs to the default timezone if the provided timezone is not supported (as if we passed null, so the same behavior that always existed). We are therefore compatible with all edge cases.2. We don't validate the timezone with `\DateTimeZone::listIdentifiers()`. It only returns full identifiers like "Europe/Paris" but it doesn't take into account "numeric" identifiers such as "+08:00" which are perfectly valid. I added a test case to ensure we stay valid with this case. + some invalid identifiers for the native `\IntlDateFormatter` are valid with the polyfill that uses `\DateTimeZone` (eg : `X`). I don't think we can validate anything safely that will work reliably on both implementations.Commits-------3b1b994 [Validator][ConstraintValidator] Safe fail on invalid timezones