IntlDateFormatter with ``'C'`` locale still broken on PHP 8.2

[Girgias]

<?php

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

Result:

Fatal error: Uncaught Error: Found unconstructed IntlDateFormatter in /in/qCifp:6
Stack trace:
#0 /in/qCifp(6): IntlDateFormatter->getLocale(1)
#1 {main}
  thrown in /in/qCifp on line 6

Process exited with code 255.

I would expect a notice or warning but not the fatal error. Please can you explain the usage?

Originally posted by @hormus in #12568 (comment)

[Girgias]

Seems #12568 didn't completely resolve the issue.

[hormus]

@Girgias thank you for new topic.
https://unicode-org.github.io/icu/userguide/locale/#canonicalization

From ICU doc:

Level 1 canonicalization. This operation performs minor, isolated changes, such as changing “en-us” to “en_US”. Level 1 canonicalization is not designed to handle “foreign” locale IDs (POSIX, .NET) but rather IDs that are in ICU format, but which do not have normalized case and delimiters. Level 1 canonicalization is accomplished by the ICU functions uloc_getName, Locale::createFromName, and Locale::Locale. The latter two APIs exist in both C++ and Java.

PHP use Locale::createFromName https://github.com/php/php-src/pull/12568/files/040927ed7946fb15cb2e3934db8a137f8794f32b#diff-a08e91205599dcf2fe2e21791185d07a67fa543d3b1cb51825eee0ae88fc24c6R113

Level 2 canonicalization. This operation may make major changes to the ID, possibly replacing entire elements of the ID. An example is changing “fr-fr@EURO” to “fr_FR@currency=EUR”. Level 2 canonicalization is designed to translate POSIX and .NET IDs, as well as nonstandard ICU locale IDs. Level 2 is a superset of level 1; every operation performed by level 1 is also performed by level 2. Level 2 canonicalization is performed by uloc_canonicalize and Locale::createCanonical. The latter API exists in both C++ and Java.

³ POSIX charset specifiers are deleted, e.g. “en_US.utf8” => “en_US”.
glibc 2.29 fixed a bug, en_US.UTF-8 started showing in 12-hour format, as was intended. If wanting to use 24-hour format, use LC_TIME=C.UTF-8 or LC_ALL=C.UTF-8

[devnexen]

So the aforementioned fix was not intended for intl to accept locales such as C but still considered as invalid. Now we can decide to abstract more and be able to do so indeed.
In the meantime, @hormus, would try/catching your code like here (example 3) work for you ?

[hormus]

ICU Canonicalization level 1 or level 2
Example 1. "C"
Example 2. "C.UTF-8" // posix syntax

<?php

error_reporting(PHP_INT_MAX);
ini_set("intl.error_level", E_WARNING);
//Locale::setDefault('it_IT');
$LocaleDefault1 = Locale::getDefault();
$LocaleDefault2 = 'C';

$copy = $LocaleDefault1 . '.';
if(is_int(strpos($copy, 'C.'))) {
$LocaleDefault1 = strtr(Locale::canonicalize($localeDefault1), array($localeDefault1 => 'en_US'));
Locale::setDefault($LocaleDefault1);
if(!$LocaleDefault2) {
$LocaleDefault2 = $LocaleDefault1;
}
}
$copy = $LocaleDefault2 . '.';
if(is_int(strpos($copy, 'C.'))) {
$LocaleDefault2 = strtr(Locale::canonicalize($LocaleDefault2), array($LocaleDefault2 => 'en_US'));
} elseif(!$localeDefault2) { // Use Default locale for null or empty string
$localeDefault2 = $localeDefault1;
}
$LocaleDefault3 = null;
try {
try {
$dateFormatter = new IntlDateFormatter($LocaleDefault2, IntlDateFormatter::FULL, IntlDateFormatter::NONE);
$LocaleDefault3 = $dateFormatter->getLocale(ULOC_VALID_LOCALE);
} catch(IntlException $e) {
}
} catch(Error $e) {
}
$b = intl_get_error_code();
var_dump($b, $LocaleDefault3, $LocaleDefault1);

?>

This Is my php fallback, $localeDefault2 Is code input or output by user.

Locale::canonicalize('C') don't convert to en_US_POSIX for this user #12561 (comment) my fallback convert explicit to en_US

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

[devnexen]

php 8.2.16/8.3.2 works for me with your code snippet.