What's the action plan here? Using intl for datetime doesn't sound right since that's the not the database used to create datetimezone objects used in datetime objects. Is it issue with datetimezone and intl having different sources for timezone data or they represent 2 different things?

I've invesigated the timezone info from Intl a bit, see also

• https://github.com/unicode-org/icu/tree/master/icu4c/source/data/zone
• https://github.com/unicode-org/icu/blob/master/icu4c/source/data/misc/timezoneTypes.txt
• https://github.com/unicode-org/icu/blob/master/icu4c/source/data/misc/metaZones.txt

this could be leveraged by a new TimezoneBundle in the Intl component, solving #26851 #22262, #25165 while at it.

From what ive seen so far, timezoneTypes.txt provides the aliases from intl to datetimetz.

I played around with it already (see https://github.com/ro0NL/symfony/commit/2ef271bf4096dc48031888da23f424c43673364a) but ran into some compile issues :(

https://hub.docker.com/r/jakzal/php-intl/ is missing the git binary, so doesnt work well out-of-the-box, and locally im stuck on icu 55. Would be nice if @jakzal could fix it ;)

https://hub.docker.com/r/jakzal/php-intl/ is missing the git binary, so doesnt work well out-of-the-box, and locally im stuck on icu 55. Would be nice if @jakzal could fix it ;)

For now you can just create your own image based on the above and add git into it (I added jakzal/docker-symfony-intl#6 for myself).

@rvanlaak the issue here with the difference in timezones is related to BC.

Intl is more up to date then PHP, which includes still some BC timezones.

for America/Punta_Arenas see https://3v4l.org/mfjIc if we look at https://github.com/unicode-org/icu/blob/master/icu4c/source/data/misc/metaZones.txt#L2268 we see it's BC, so makes sense Intl actually returns Etc\Unknown here.

Asia/Atyrau => https://github.com/unicode-org/icu/blob/master/icu4c/source/data/misc/metaZones.txt#L2724
etc.

Others, e.g. Europe/Busingen, are probably added in a later version, see https://3v4l.org/mJdOW

Great work on investigating the root cause. 👏 I think solving this issue is a matter of choosing:

1. Supporting Intl everywhere, and solve this issue by a) alias intl to datetime and/or thereafter b) intersecting both sets to be sure no colissions can happen.
2. Decide to not supporting intl, and solely use PHP's identifiers in the form type.
3. As the impact of this issue is small, live with it and keep this a documented userland problem.

We use our custom form type that intersects both sets since we found out about this bug, so we would prefer 1.

the relevant timezone ids can be used both with php datetimezone and intl, there's no difference here.

we should only allow for timezone ids from intl that are supported by datetimezone, in a dedicated timezonebundle (symfony/intl) so the list is fixed and based on latest ICU.

the unsupported ones are not really relevant anyway :) https://3v4l.org/1Xit4

alternatively the timezonebundle could provide both lists, for the form type: we've recently added the input option (#23648)

so we could decide which list to use based on input=intltimezone vs. input=datetimezone

@rvanlaak im not sure about excluding timezones not supported by \IntlTimeZone. Symfony doesnt support it as an underlying model.. only string and \DateTimeZone and for those the current list works fine.

So the topic is if we should exclude BC zones in the TimezoneType list.... it didnt raise any issues so far and it's basically is a BC break :) so im skeptical.

Looking at the timezone widget from Google Calendar, even there BC zones seem to be included (e.g. America/Punta_Arenas).

I've also opened #28836 to propose switching to symfony/intl instead. That would still includes BC zones though, but we could check for that from there on (if needed).

So im 👎 for the suggested change here as is, but after #28836 we have a much better base to check it and e.g. support input=intltimezone to use \IntlTimeZone as underlying model. Only then the BC zones need to be excluded, as it's technically unsupported for the model).

For now, i think your best of to set the available zones manually.