`\IntlDateFormatter` constructor throws an exception for unknown locales since 8.1.25

[mpdude]

Description

Since PHP 8.1.25 and due to the changes in #12282, the following code throws an IntlException:

<?php
 new IntlDateFormatter(
        'xx',
        IntlDateFormatter::FULL,
        IntlDateFormatter::FULL,
        null,
        null,
        'w'
    );

There may be many reasons why the locale value is invalid – it might be taken from the LANG environment variable and be set to C, it might be parsed from request parameters (the reason behind #12533), or it might be a locale name that is valid on one system but is not in the list of generated/supported locales on another system.

While I agree that ideally, all these conditions should be checked and caught beforehand, and I also agree that fixing #12282 without a sensible locale to assume might be difficult, my point is that turning this condition into an exception in a bugfix release is a breaking change that should be reverted.

PHP Version

PHP 8.1.25

Operating System

No response

[mpdude]

@devnexen I'd appreciate to hear your thoughts on this

[devnexen]

What can eventually be done is for 8.1/8.2 just returning a failure instead but keeping the exception otherwise.

[mpdude]

Should Locale::setDefault() behave the same way?

[Seldaek]

We just hit this issue as well in a test case where we used new \IntlDateFormatter(Locale::getDefault(), ...) and due to a previous
state resetting thing we have between tests we called Locale::setDefault with 'C' as locale. So we ended up passing C as the locale, and this throws.

php -r 'Locale::setDefault("C"); var_dump(Locale::getDefault()); new \IntlDateFormatter(Locale::getDefault());'
Command line code:1:
string(1) "C"
PHP Fatal error:  Uncaught IntlException: datefmt_create: invalid locale: U_ILLEGAL_ARGUMENT_ERROR in Command line code:1

So yes IMO setDefault should definitely throw as well to make this more obvious where the failure comes from.

And I'd say maybe 'C' should be accepted as locale, as it is a valid one for setlocale and the system overall, but I'm not sure if that's really sensible or not in the IntlDateFormatter context.

[drbyte]

@Seldaek wrote:

And I'd say maybe 'C' should be accepted as locale, as it is a valid one for setlocale and the system overall

I agree.

According to https://learn.microsoft.com/en-us/cpp/c-runtime-library/locale-names-languages-and-country-region-strings?view=msvc-170 it would seem that 'C' is a valid default locale which signifies that the host system hasn't yet defined a locale.
I don't think that warrants fatally throwing an exception.

Perhaps the IntlDateFormatter needs to define fallback logic instead?

[hormus]

For all PHP version.
The locale class
The null or empty string obtains the "root" locale. The "root" locale is equivalent to "en_US_POSIX" in CLDR.

<?php
$coll    = collator_create( 'C' );
$res_val = collator_get_locale( $coll, Locale::VALID_LOCALE );
$res_act = collator_get_locale( $coll, Locale::ACTUAL_LOCALE );
printf( "Valid locale name: %s\nActual locale name: %s\n",
         $res_val, $res_act );
?>

Expected result:

Valid locale name: root
Actual locale name: root

<?php

Locale::setDefault('');
$a = new IntlDateFormatter('', IntlDateFormatter::FULL, IntlDateFormatter::FULL);
var_dump(Locale::getDefault(), $a->getLocale(ULOC_VALID_LOCALE));
?>

Expected result:

string(11) "en_US_POSIX"
string(11) "en_US_POSIX"

Convert native ICU from "C" to "en_US_POSIX"

<?php
Locale::canonicalize(Locale::getDefault());

https://github.com/php/php-src/blob/master/ext/intl/locale/locale_methods.c#L798-L805 get_icu_value_src_php function

[mpdude]

If there is a root locale, maybe the IntlDateFormatter should fall back to that when the given locale is invalid?

[Girgias]

Fixed by #12568