Skip to content

Conversation

@MatTheCat
Copy link
Contributor

Q A
Branch? 7.3
Bug fix? yes
New feature? no
Deprecations? no
Issues Fix #31057, close #29610
License MIT

From #29610 (comment) and https://stackoverflow.com/q/71779588; I guess this wasn’t fixed before because it needed #57960 (which is why this PR targets 7.3).

if (isset($options['calendar'])) {
$calendar = $options['calendar'];
} else {
$calendar = new \IntlGregorianCalendar();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this adds a strict dependency to ext-intl for the default configuration because symfony/polyfill-intl-icu does not provide a polyfill for IntlGregorianCalendar

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw, this also changes the existing behavior for forms for the default setup, which might cause other issues. Maybe you should instead solve your case by configuring a calendar option (either explicitly when using the DateType or project-wide by registering a FormTypeExtension replacing the default value of the calendar option)

@MatTheCat
Copy link
Contributor Author

Better fixed in the documentation

@MatTheCat MatTheCat closed this Oct 21, 2025
@MatTheCat MatTheCat deleted the ticket_31057 branch October 21, 2025 16:55
@stof
Copy link
Member

stof commented Oct 21, 2025

Another thing to be careful: when passing a calendar object (instead of one of the numeric constants), IntlDateFormatter ignores the timezone that was used to instantiate the formatter. the timezone used in the IntlCalendar object wins instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants