You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
IntlDateFormatter returns incorrect week number for an invalid locale (and doesn't throw an exception either) #12282
IMHO this is a breaking change that should not go into a bugfix release.
There might be multiple reasons why you might be using an invalid locale string, e. g. the locale is being taken from a request parameter, is taken from the LANG environment variable and is set to C or the locale requested is simply not available (generated) on a particular system/installation.
While I agree that all those should be checked/caught by the surrounding/preceding code, turning this into an exception in a bugfix release is not an option IMHO.
Also, I think something that throws an exception should not be added in a RC3 (like 8.3.0RC3), but that's another story.
Reacted by Chris Brown, TussendoorHQ, bucsi and Penélope Gonçalves
If it doesn't throw an exception then I think that it should at least return the correct week number, even if the locale is invalid. The documentation is not very clear, but as far as I can see the 'w' pattern returns the ISO week number. If that's the case then surely the ISO week number is independent of the locale?
I agree that the locale could be validated elsewhere, but my point was that if 'w' is the pattern for the ISO week number then in the example above it should give 38 rather than 39 as the ISO week number does not depend on locale (well, at least the value though the character representation may).
Ok, my misunderstanding then. As I said, the documentation isn't very clear. I had assumed that 'w' is the pattern for the ISO week number. If it isn't, do you know what is?
Ok, my misunderstanding then. As I said, the documentation isn't very clear. I had assumed that 'w' is the pattern for the ISO week number. If it isn't, do you know what is?
The "week of year" varies. ISO 8601 has one specification, but that doesn't mean every locale uses it.
Values calculated for the Week of Year field range from 1 to 53 for the Gregorian calendar (they may have different ranges for other calendars). Week 1 for a year is the first week that contains at least the specified minimum number of days from that year. Weeks between week 1 of one year and week 1 of the following year are numbered sequentially from 2 to 52 or 53 (if needed). For example, January 1, 1998 was a Thursday. If the first day of the week is MONDAY and the minimum days in a week is 4 (these are the values reflecting ISO 8601 and many national standards), then week 1 of 1998 starts on December 29, 1997, and ends on January 4, 1998. However, if the first day of the week is SUNDAY, then week 1 of 1998 starts on January 4, 1998, and ends on January 10, 1998. The first three days of 1998 are then part of week 53 of 1997.
We have update our php version to the lastest yesterday (8.2.12) and the bug still provoke 500 in our production environment : Uncaught PHP Exception IntlException: "datefmt_create: invalid locale: U_ILLEGAL_ARGUMENT_ERROR" at /var/www/web/vendor/symfony/form/Extension/Core/DataTransformer/DateTimeToLocalizedStringTransformer.php line 179
Concern line in Symfony core : $intlDateFormatter = new \IntlDateFormatter(\Locale::getDefault(), $dateFormat, $timeFormat, $timezone, $calendar, $pattern ?? '');
Activity
mpdude commentedon Oct 30, 2023
IMHO this is a breaking change that should not go into a bugfix release.
There might be multiple reasons why you might be using an invalid locale string, e. g. the locale is being taken from a request parameter, is taken from the
LANGenvironment variable and is set toCor the locale requested is simply not available (generated) on a particular system/installation.While I agree that all those should be checked/caught by the surrounding/preceding code, turning this into an exception in a bugfix release is not an option IMHO.
Also, I think something that throws an exception should not be added in a RC3 (like 8.3.0RC3), but that's another story.
campbell-m commentedon Oct 31, 2023
If it doesn't throw an exception then I think that it should at least return the correct week number, even if the locale is invalid. The documentation is not very clear, but as far as I can see the 'w' pattern returns the ISO week number. If that's the case then surely the ISO week number is independent of the locale?
mpdude commentedon Oct 31, 2023
I am afraid it is:
w3c/sdw-time#42
mpdude commentedon Oct 31, 2023
Maybe you should not expect a particular week number for an invalid locale, given that the week number depends on the locale?
Garbage (locale) in, garbage (week no) out, but no exception in a bugfix release.
If we want stricter locale validation, that needs to go elsewhere or in more places than just this.
campbell-m commentedon Oct 31, 2023
I agree that the locale could be validated elsewhere, but my point was that if 'w' is the pattern for the ISO week number then in the example above it should give 38 rather than 39 as the ISO week number does not depend on locale (well, at least the value though the character representation may).
mpdude commentedon Oct 31, 2023
The week number does depend on the locale, see this:
campbell-m commentedon Oct 31, 2023
Ok, my misunderstanding then. As I said, the documentation isn't very clear. I had assumed that 'w' is the pattern for the ISO week number. If it isn't, do you know what is?
damianwadley commentedon Oct 31, 2023
The "week of year" varies. ISO 8601 has one specification, but that doesn't mean every locale uses it.
https://www.unicode.org/reports/tr35/tr35-dates.html#week-of-year
campbell-m commentedon Nov 1, 2023
Many thanks for the clarifications. I understand the 'w' pattern a lot better now.
filozofer commentedon Nov 9, 2023
We have update our php version to the lastest yesterday (
8.2.12) and the bug still provoke 500 in our production environment :Uncaught PHP Exception IntlException: "datefmt_create: invalid locale: U_ILLEGAL_ARGUMENT_ERROR" at /var/www/web/vendor/symfony/form/Extension/Core/DataTransformer/DateTimeToLocalizedStringTransformer.php line 179Concern line in Symfony core :
$intlDateFormatter = new \IntlDateFormatter(\Locale::getDefault(), $dateFormat, $timeFormat, $timezone, $calendar, $pattern ?? '');With inputs :
So it seems than "cz" locale is considerate as an invalid locale ><
CZ is part of the Iana list of language : https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
So... bug or misconfiguration of our app ?
mpdude commentedon Nov 9, 2023
The fix (revert of the change) will land in the next 8.1 and 8.2 bugfix release. PHP 8.2.12 was released before the change was made.
Caution: PHP 8.3 will bring back the change.
filozofer commentedon Nov 9, 2023
We pass our users from "cz" locale to "cs" and it works again. Thanx for your response.