[Validation] Documented the intlCompatible option in Timezone constraint #12057
Conversation
|
Thanks for the review Roland. I've reworded most of it. |
| The default value of this option depends on your application. If the | ||
| :doc:`Intl component </components/intl>` is available in the application, the | ||
| default value is ``true``; otherwise, it's ``false`` by default. | ||
|
|
There was a problem hiding this comment.
so this option is really confusing i guess :)
both PHP+SF intl timezones are considered valid, regardless of this option. The SF intl timezones are only considered valid if the component is available.
However, because of 2 possible different versions of ICU (the version used to compile SF intl vs. the version used by ext-intl compiled in PHP) an edge case might occur:
if a timezone is considered valid by SF intl (based on the latest ICU version in SF), it might be unknown when using it in PHP (e.g. $model = \IntlTimeZone::createTimeZone($tzValidatedBySfIntl);) due a different ICU version PHP is compiled with.
There was a problem hiding this comment.
so the TLDR of this option is, it ensures you can use the timezone ID with IntlTimeZone::createTimeZone($tz) :) and you'll never get Etc/Unknown
There was a problem hiding this comment.
Yes, the name of this option is super confusing. The name tells me that true/false enables/disables support for Intl timezones.
But you say that Intl is unconditionally enabled. The, when should I set this option to true/false and what does it do? Thanks.
There was a problem hiding this comment.
did you see the last comment?
"intl" can mean 2 things: SF Intl or PHP Intl (https://www.php.net/manual/en/book.intl.php). Here it means the latter
We have no control of the ICU version used by PHP, hence this option to ensure a valid timezone ID when using \IntlTimeZone for a model (this class is provided by PHP Intl)
There was a problem hiding this comment.
so TLDR :D
set this option to true if you're modelling the validated timezone ID with \IntlTimeZone, or aim to do so in the future and you want to prepare your data already
There was a problem hiding this comment.
Phewwww ... I think I finally understood this! Please review the latest reword ... and thanks for your patience 😅
|
I think we should the reordering in |
|
@xabbuh but this article was introduced in Symfony 4.3 version, right? 🙈 |
|
Sorry, I missed that the constraint was added in 4.3. 🙈 |
…ezone constraint (javiereguiluz) This PR was squashed before being merged into the 4.3 branch (closes #12057). Discussion ---------- [Validation] Documented the intlCompatible option in Timezone constraint Fixes #11502. In addition to documenting the `intlCompatible` option, it sorts all the options alphabetically, like we always do for constraints. Commits ------- 6440a37 [Validation] Documented the intlCompatible option in Timezone constraint
Fixes #11502.
In addition to documenting the
intlCompatibleoption, it sorts all the options alphabetically, like we always do for constraints.