Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[RFC][Form] Change TimezoneType to Intl sources / translate timezone choice labels #28836

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ro0NL opened this issue Oct 12, 2018 · 10 comments
Closed
Labels
Form Intl RFC RFC = Request For Comments (proposals about features that you want to be discussed)

Comments

@ro0NL
Copy link
Contributor

ro0NL commented Oct 12, 2018

Description
Currently the TimezoneType does not depend on symfony/intl (unlike LanguageType etc.), but uses vanilla PHP based on \DateTimeZone::listIdentifiers().

There are several issues (#26851, #17628, #17636) that request to use localized zone labels.

For that i've finished #28831 to provide the actual translations, based on ICU, just like languages, etc.

However it doesnt mean we should switch from \DateTimeZone::listIdentifiers() to TimezoneBundle::getZoneNames() per se, hence the RFC.

I see several options:

  1. keep using \DateTimeZone::listIdentifiers() and only translate using TimezoneBundle
  2. switch to TimezoneBundle as a new feature (including translating)
  3. add an option intl => false to optionally switch
  4. option 3 + deprecating not setting it to true (force intl in 5.0)
  5. option 2 + deprecating submitting unsupported zones (few)

Personally i'd prefer symfony/intl so there's no environment dependency, and we have better control to blacklist/mutate etc.

Related

  • consider adding input=intltimezone to leverage \IntlTimeZone as underlying model
  • the current regions option relies on \DateTimeZone::listIdentifiers(), so if in any scenario Intl will be used the option is incompatible, meaning we either implement a fallback or deprecate it all together (favored by group_by to let the user decide in all cases)
  • re-consider timezone sorting (going from -xx:00 to +xx:00 makes sense and is intuitive, given the GMT+- offset is included in the label - see e.g. [Intl] Add Timezones #28831 (comment))

Thougts?

@stof
Copy link
Member

stof commented Oct 12, 2018

Whatever gets decided here, backward compatibility requires that the dependency to symfony/intl stays optional (as the form type is currently usable without it).

@ro0NL
Copy link
Contributor Author

ro0NL commented Oct 12, 2018

of course :) BC guaranteed, however symfony/intl is already a dependency of symfony/form i just found out

"require": {
"php": "^7.1.3",
"symfony/event-dispatcher": "~3.4|~4.0",
"symfony/intl": "~3.4|~4.0",

i actually expected it to be a soft-dep :) meaning either we should fix that (we recently updated the types to throw if unavailable :S) or option 2 is viable :D

@stof
Copy link
Member

stof commented Oct 12, 2018

hmm indeed, I confused with the validator component, where it is a soft dependency.

@ro0NL
Copy link
Contributor Author

ro0NL commented Oct 12, 2018

join the club :) i forgot to move the dep myself in #28610

now thinking about it.. is that a BC break or would a changelog note be sufficient?

@ro0NL
Copy link
Contributor Author

ro0NL commented Oct 13, 2018

So i've compared the zones from \DateTimeZone::listIdentifiers() vs. the compiled list from #28831, to see what's the impact on the practical side.

To me what's important, is that all zones are compatible with \DateTimeZone. The ones incompatible with \IntlTimeZone are BC, and are very few actually (see also #22302), i'm not sure we care for now. Esp. since Symfony core doesnt use it AFAIK.

Results are pretty close, the difference mostly comes from a few different notations (Etc/UTC vs UTC) , and PHP and ICU using different form of aliases.

E.g. America/Argentina/Buenos_Aires vs. America/Buenos_Aires:

AFAIK we should follow ICU here.

Zone PHP SF DateTimeZone IntlTimeZone
count 425 433
Africa/Asmara
America/Argentina/Buenos_Aires
America/Argentina/Catamarca
America/Argentina/Cordoba
America/Argentina/Jujuy
America/Argentina/Mendoza
America/Atikokan
America/Indiana/Indianapolis
America/Kentucky/Louisville
America/Punta_Arenas
Asia/Atyrau
Asia/Famagusta
Asia/Ho_Chi_Minh
Asia/Kathmandu
Asia/Kolkata
Asia/Tomsk
Asia/Yangon
Atlantic/Faroe
Europe/Kirov
Europe/Saratov
Pacific/Chuuk
Pacific/Pohnpei
UTC
Africa/Asmera
America/Buenos_Aires
America/Catamarca
America/Coral_Harbour
America/Cordoba
America/Indianapolis
America/Jujuy
America/Louisville
America/Mendoza
America/Montreal
America/Santa_Isabel
Asia/Calcutta
Asia/Katmandu
Asia/Rangoon
Asia/Saigon
Atlantic/Faeroe
CST6CDT
EST5EDT
Etc/GMT
Etc/UTC
MST7MDT
PST8PDT
Pacific/Johnston
Pacific/Ponape
Pacific/Truk

Snippet used: https://gist.github.com/ro0NL/fd815d6242ff8ee8116ee1acfb6db9a7

@javiereguiluz javiereguiluz added Form Intl RFC RFC = Request For Comments (proposals about features that you want to be discussed) labels Oct 13, 2018
@javiereguiluz
Copy link
Member

This improvement would be great and would indeed bring consistency with the other Intl parts.

Thanks for listing the differences. They are not very important ... but what are you proposing for existing apps that use the old TZ? How could they transition to the new TZ? Thanks!

@ro0NL
Copy link
Contributor Author

ro0NL commented Oct 16, 2018

I've added option 5 in the issue, describing the ideal scenario: switch to Intl, while keep supporting any submitted value from the old PHP list. At this point i'd like to trigger a deprecation, but it might be a bit complex... not sure yet.

More pragmatically would be to just make the switch as a new feature (option 2). Technically we did the same-ish in #28833 😅

If we accept the feature (one way or another), i can have a look after #28831 / #28846

@stof
Copy link
Member

stof commented Oct 16, 2018

I think the important thing for BC is that new DateTimeZone($zone) works, more than having it included in \DateTimeZone::listIdentifiers() (assuming the validator is not based on \DateTimeZone::listIdentifiers() only of course). And according to your analysis, new DateTimeZone($zone) seems to support them all.
Compatibility with new \IntlTimeZone($zone) was already not guaranteed at 100%, due to some unsupported ones (see Asia/Tomsk in your list for instance)

fabpot added a commit that referenced this issue Oct 25, 2018
This PR was merged into the 4.2-dev branch.

Discussion
----------

[Form] Deprecate TimezoneType regions option

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | yes
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | #28848
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->

I know i've added this option myself in 4.1, but given my recent development for #28624 i realized it's an opinionated feaure, which can/should be solved on user-side (`choice_filter/choice_loader` and/or `group_by`).

- blocks translations as we dont have them (see #28831)
- blocks possibility of switching to Intl zones which doesnt really have this filter feature (see #28836)

~While at it, i solved a few issues with `OptionsResolver` that is able to deprecate options as of 4.2 also.~ Fixed in #28878

- when resolved trigger the deprecation
- allow to opt-out from triggering the deprecation
- dont trigger deprecation for default values (only given ones)

Commits
-------

5cb532d [Form] Deprecate TimezoneType regions option
@ro0NL ro0NL changed the title [RFC] Change form TimezoneType to Intl sources [RFC][Form] Change TimezoneType to Intl sources / translate timezone choice labels Apr 16, 2019
fabpot added a commit that referenced this issue Apr 27, 2019
This PR was squashed before being merged into the 4.3-dev branch (closes #31195).

Discussion
----------

[Form] Add intltimezone input to TimezoneType

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | #22302 (ref #28836)
| License       | MIT
| Doc PR        | symfony/symfony-docs#11463

cc @rvanlaak

Commits
-------

e169dfb [Form] Add intltimezone input to TimezoneType
fabpot added a commit that referenced this issue Apr 29, 2019
…country mapping (ro0NL)

This PR was squashed before being merged into the 4.3-dev branch (closes #31262).

Discussion
----------

[Intl] Update timezones to ICU 64.2 + compile zone to country mapping

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | #...   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->

This PR compiles the zone to country mapping (and vice versa) from ICU data:
https://github.com/unicode-org/icu/blob/master/icu4c/source/data/misc/windowsZones.txt

I've recompiled timezones on master due #31162, i should do it once more when it's merged upstream.

Having this data allows compatibility between PHP timezones and ICU;
- https://www.php.net/manual/en/intltimezone.getregion.php
- https://www.php.net/manual/en/class.datetimezone.php#datetimezone.constants.per-country

For the timezone validator in Symfony, this would be required to have a compatible "regions" option, once it supports ICU as well (#28836 (comment))

Commits
-------

3018a7a [Intl] Update timezones to ICU 64.2 + compile zone to country mapping
fabpot added a commit that referenced this issue May 1, 2019
This PR was merged into the 4.3-dev branch.

Discussion
----------

[Validator] Allow intl timezones

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | ref #28836
| License       | MIT
| Doc PR        | symfony/symfony-docs#11502

This PR considers the ICU timezones (#28831) as valid, as well as the PHP ones.

Both can be used in `DateTimeZone`, but expired timezones cannot be used with `IntlTimeZone`. The `intlCompatibility` option ensures compatibility between both.

Practically this allows for both `UTC` and `Etc/UTC`, where the latter should be preferred. I.e. currently `Etc/UTC` is considered an invalid timezone ... which it's not.

Commits
-------

7294b59 [Validator] Allow intl timezones
@fabpot fabpot closed this as completed May 13, 2019
fabpot added a commit that referenced this issue May 13, 2019
…mezoneType (ro0NL)

This PR was merged into the 4.3 branch.

Discussion
----------

[Form] Add intl/choice_translation_locale option to TimezoneType

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | #28836
| License       | MIT
| Doc PR        | symfony/symfony-docs#11503

final step :)

for now i think any form of grouping is a user concern (i.e. by GMT offset or area name); see #31293 + #31295

having a special built in `group_by' => 'gmt_offset'` util would be nice, and can be done in the future.

includes #31434

Commits
-------

001b930 [Form] Add intl/choice_translation_locale option to TimezoneType
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Form Intl RFC RFC = Request For Comments (proposals about features that you want to be discussed)
Projects
None yet
Development

No branches or pull requests

4 participants