Why does IntlDateFormatter not return "false" even with obviously made-up locale/language strings?

331 views Asked by At

Source:

https://www.php.net/manual/en/intldateformatter.create.php

Quote:

Return Values ¶ The created IntlDateFormatter or FALSE in case of failure.

Code:

$fmt = new IntlDateFormatter( "en_US" ,IntlDateFormatter::FULL, IntlDateFormatter::FULL,
    'America/Los_Angeles',IntlDateFormatter::GREGORIAN  );
var_dump($fmt);

$fmt = new IntlDateFormatter( "madeupfakenonexistent" ,IntlDateFormatter::FULL, IntlDateFormatter::FULL,
    'America/Los_Angeles',IntlDateFormatter::GREGORIAN  );
var_dump($fmt);

Actual output:

object(IntlDateFormatter)#3 (0) {
}
object(IntlDateFormatter)#2 (0) {
}

Expected output:

object(IntlDateFormatter)#3 (0) {
}
bool(false)

PHP:

7.4.12

Conclusion:

The manual is lying or I'm misinterpreting it.

2

There are 2 answers

0
IMSoP On

You are misinterpreting the manual, but it does also appear to be incorrect.

Your first mistake is that a constructor in PHP cannot return anything other than an object of the specified type. The only way it can signal an error is by throwing an exception. That page however also documents the static method IntlDateFormatter::create and the plain function datefmt_create, both of which could return false.

Your second mistake is assuming that "returns false on error" means that every possible error will be detected and return false. In this particular case, there appears to be no validation of whether the locale specified matches one in any particular list. Passing unexpected values for other parameters is considered an error, e.g. $fmt = new IntlDateFormatter ("en_US", 99999, IntlDateFormatter::FULL, 'America/Los_Angeles', IntlDateFormatter::GREGORIAN);.

Where you appear to be accidentally correct is that none of these functions appear to return false for such errors. For new IntlDateFormatter, that will trigger an exception, because it can't do anything else; for IntlDateFormatter::create and datefmt_create it will return null, which is the standard PHP behaviour for bad arguments as noted here.

I'm not 100% sure, but looking at the relevant source code I don't think there are any cases where these functions return false, so the manual should perhaps be corrected/updated.

0
Greenflash On

This has now been fixed in PHP. See Issue #12282.