[Vote] More Appropriate Date/Time Exceptions

Hi,

I've just opened the vote for "More Appropriate Date/Time Exceptions".
It runs until December 31st, 24:00 UTC.

You can vote at:
https://wiki.php.net/rfc/datetime-exceptions#voting

Hi Derick,

Thank you for your work on this. I like the idea of having more specific
exceptions to avoid having to parse generic exception/warning strings.

However, I voted No because there doesn't seem to be an implementation
currently, and I'm concerned about introducing differences in error
handling between the procedural and object-oriented date functions.

Is there a rational for why the procedural date functions should continue
producing generic warnings/exceptions, rather than consistently using the
same exception hierarchy as the OO interface? I fear this could make it
harder for users to switch between the procedural and OO APIs, as some
errors might have to be handled in a different way.

Also, could maintaining parity between the procedural/OO APIs be more
difficult if they each implement error handling differently?
Perhaps I'm mistaken, but I thought that currently the procedural date
functions are simple aliases of the corresponding object method.

You're mistaken then. The procedural versions never threw exceptions,
and changing to that now is a big BC break, which is not warranted.

It was always a deliberate choice (since 2014) that the procedural
versions don't throw exceptions, and the OO versions do. The RFC is not
wanting to change this behaviour. And rightfully so.

Thank you for the clarification. I know that the functions date_create
and date_create_immutable have this difference in behavior from the
DateTime and DateTimeImmutable constructors, and this is documented
in the PHP manual.

But for most other date functions there doesn't seem to be any difference.
E.g. date_create_from_format and DateTime::createFromFormat both return
false on failure.

Likewise, date_interval_create_from_date_string and DateInterval::createFromDateString
both output a warning and return false on failure, as do date_modify and DateTime::modify.
See https://3v4l.org/HjXee.

So I'm struggling to understand why it's okay to make a BC break for the OO API,
but not for the procedural API. As long as a BC break is being made, why not
change date_create and date_create_immutable throw exceptions like the
constructors, rather than trying to preserve BC for only the procedural API
and ending up with even more inconsistent behavior?

Best regards,
Theodore