0

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.

user379490
  • 159
  • 5
  • The PHP manual is written by the community, so rather than saying it is "lying", you could just say "needs correcting", and once you're sure you could submit the correction yourself, which can now be done [via a github pull request](https://github.com/php/doc-en). – IMSoP Jan 14 '21 at 21:06

1 Answers1

0

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.

IMSoP
  • 89,526
  • 13
  • 117
  • 169