Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119185
To: Derick Rethans <derick@php.net>, PHP Developers Mailing List
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [Vote] More Appropriate Date/Time Exceptions
Thread-Index: AQHZEJFp+oRHu8hqdkiFUMHkVnUkuK5xAbdkgAAj+gCAAqfg9Q==
Date: Sun, 18 Dec 2022 16:47:47 +0000
Message-ID:
 <BN7PR05MB40339538DE789250610BDCA0DEE49@BN7PR05MB4033.namprd05.prod.outlook.com>
References:
 <alpine.DEB.2.23.453.2212151424240.462551@singlemalt.home.derickrethans.nl>
 <BN7PR05MB403334EA297BBDBD311FF3CCDEE69@BN7PR05MB4033.namprd05.prod.outlook.com>
 <0E149CE3-9124-4473-92FE-ABF11B585C77@php.net>
In-Reply-To: <0E149CE3-9124-4473-92FE-ABF11B585C77@php.net>
Accept-Language: en-US
Content-Language: en-US
msip_labels:
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [z4eBG4YAwcOFgm3O3544w+YWUv/HmZomUUC1Krw70Cw=]
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN7PR05MB4033:EE_|CY4PR0501MB3828:EE_
x-ms-office365-filtering-correlation-id: 4058f0ac-34b0-44e2-4770-08dae11797ed
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 CeQ+hABXaTCeek6v47Tw1RzEmR3lu8ww82gIRQ+TtjIyJbesy4rX8j/6W5HYoBL9u36KemmTKuP/4l/sh762MHLL7IwNvV0K4aVyn7/jlGCc5RQCUzkt5kn++yavx9NQQicZNz+YxofgqWeluRt6OiJa3DAr7tHWNNzL2/cj/gIbnGFoyMHn7YeApSv9iVI5WiXpULI9KZ0+YHU3meqJuKlFIvsQ7ECqG6blgspAAOeDBMB1ylaiufIm061vKvHegfW7wFq77hxgspHL6RBtqe36RZylIvksOyqyWzXnhcS7MIExUU1g+93j2DWplBdb5/E09NVn92ch+rjPp7dDQOsug2QYGLBjwmcKzqD6yr3hJtMACpKNvVMVaJ8amt/2mlo0oG2arx6m9SdL5XkOIsjjqHUIEuFU+pZBuR0p0wM8AdP4VDAMjOCv0RyxrH/mOU7XztOMXaHq8H09Wyvr5q3m+HPZYp3o4ZZF1j6IVEzc60zJZMc1BuFM9I7VKJES75G3ZKGFiywlruUOpw7OnZ/+joG4k33MhVyi94l3fIX9ITTdiEbvfduQiJE4V9+xW0kyn1J7nKjelem1NPA09mUCuoPVs/E/JyOjXmT2OdnSgeovfG5coq6PmFPq99eCKLmBSM678AOD/96Z8+qciw==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?/mBk1we97Hx5PFq15VSEzTtyY1YF01XC6IFTtkVgtcJN552KYg8bbEBbDO?=
 =?iso-8859-1?Q?ii//LaiOaNwV+Uh0oRlKPK27CVA/eaXkfcLC+JnTDeoC/c0dgyDraCWYJ/?=
 =?iso-8859-1?Q?zKtF1/MRKNiWeu4fTROAAqBZpWDIwdceeeQv7A2YXJ7hu3BiQ9aYd/SnbN?=
 =?iso-8859-1?Q?/pxO/5+yG0miScldWus+rZGTcd8xsetV18/9CiRWwkbPLdLawQ8fOjVEHc?=
 =?iso-8859-1?Q?ap9k7z/aiOP/FirctG2JA8cpBThdGw52n5fJHRZ4bFtZWCP7gx3ryZZ4oJ?=
 =?iso-8859-1?Q?XeSnVKyw3UoXchG6rHTcyJJo30xmaQF69xvT+feLP3ZfadEKBlvmp3DLfz?=
 =?iso-8859-1?Q?UXUTE217PU3SZNM0R+6E5wgrLZi7TRUMU2zreYtU3vZ/Hu1CReqPbMJ9Zw?=
 =?iso-8859-1?Q?fTsUx3dctWl4IDT6cbaYPWI2AF6bnoZcBgonOX25Vu3UUEo1g5s56zl85H?=
 =?iso-8859-1?Q?evOZ/0b5FyEjRtgb9Mt/t3bMahWyy9pxuwTSZCSZlx8LYQM78jExYOUzF0?=
 =?iso-8859-1?Q?YtdxvOPdtucuW5gxHm6UaUIgbJajWdCck3uc8gnCluk+V9/EXXPxSxt0/2?=
 =?iso-8859-1?Q?1zSyu3Hz7BJ966UePzikYGdoo6WJTu34UmaBzH31d4DZ998oD1Lq9hF5xO?=
 =?iso-8859-1?Q?qk0No6ZFHorW5+419jA0wI29m6uVE2krQPkZZ/StAe1/1vhC6IJULkAskF?=
 =?iso-8859-1?Q?t1uRYVwf+RkTMfev6l692+pCVAVKntBftNXfxLnNZdrRhbJtM8vOyzMnkO?=
 =?iso-8859-1?Q?yavSD0sjYwPo2YlggihpYWzGYOYTN326X9uYW0Eg+05eIb0WOdvqoGxiDD?=
 =?iso-8859-1?Q?sNkwVfvU0RkPD/b/OZfHgb0uObm6WIw6LbftbhSIZ4T/l0TxN67tmGrXHo?=
 =?iso-8859-1?Q?L61T0VzsUG1wcwJIqU7aWSsdXNWkWWLxz8iF8KFz5rJ4lShgbDR5qSAQeq?=
 =?iso-8859-1?Q?t+BRwinEYPIfwpBAihreTR/nqsCwvk5vLB2UHGdSBiigj/ARRHWdv1rgKr?=
 =?iso-8859-1?Q?Y1ptOUW1r1lCt9DE1JEctwAmG0wv4ByuFFcO6MZzvARHj0xBIdmbwdfm77?=
 =?iso-8859-1?Q?HOxT1PTjlx5F7S8/K4dGJc3LZ4s0T896FtSZIL23cKT/59panoVvB/dIZl?=
 =?iso-8859-1?Q?uPdVGX06LwwGFzdNfzGuekLo++4Dm/9V4sRwjBiO0mKFrVyrpnYDC7Bc2I?=
 =?iso-8859-1?Q?f0hlUL4tCs+M5dfH2k+ytp/kQm6CtEce27wPzFUi6+p/rIyd9J69HhgYBN?=
 =?iso-8859-1?Q?m/pZ46rqJ9zt27ciptC/g2+2jwupPaGDrBQPvnX7NtwCKCcsBrmjT1J84E?=
 =?iso-8859-1?Q?frca61/1T/JemMlfcE7t9gbdmg=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN7PR05MB4033.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 4058f0ac-34b0-44e2-4770-08dae11797ed
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2022 16:47:47.5441
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0501MB3828
Subject: Re: [PHP-DEV] [Vote] More Appropriate Date/Time Exceptions
From: theodorejb@outlook.com (Theodore Brown)

On Fri, Dec 16, 2022 at 5:09 PM Derick Rethans <derick@php.net> wrote:=0A=
>On 16 December 2022 21:34:16 GMT, Theodore Brown <theodorejb@outlook.com> =
wrote:=0A=
>>On Thu, Dec 15, 2022 at 8:27 AM Derick Rethans <derick@php.net> wrote:=0A=
>>=0A=
>>> Hi,=0A=
>>>=0A=
>>> I've just opened the vote for "More Appropriate Date/Time Exceptions".=
=0A=
>>> It runs until December 31st, 24:00 UTC.=0A=
>>>=0A=
>>> You can vote at:=0A=
>>> https://wiki.php.net/rfc/datetime-exceptions#voting=0A=
>>=0A=
>> Hi Derick,=0A=
>>=0A=
>> Thank you for your work on this. I like the idea of having more specific=
=0A=
>> exceptions to avoid having to parse generic exception/warning strings.=
=0A=
>>=0A=
>> However, I voted No because there doesn't seem to be an implementation=
=0A=
>> currently, and I'm concerned about introducing differences in error=0A=
>> handling between the procedural and object-oriented date functions.=0A=
>>=0A=
>> Is there a rational for why the procedural date functions should continu=
e=0A=
>> producing generic warnings/exceptions, rather than consistently using th=
e=0A=
>> same exception hierarchy as the OO interface? I fear this could make it=
=0A=
>> harder for users to switch between the procedural and OO APIs, as some=
=0A=
>> errors might have to be handled in a different way.=0A=
>>=0A=
>> Also, could maintaining parity between the procedural/OO APIs be more=0A=
>> difficult if they each implement error handling differently?=0A=
>> Perhaps I'm mistaken, but I thought that currently the procedural date=
=0A=
>> functions are simple aliases of the corresponding object method.=0A=
>=0A=
> You're mistaken then. The procedural versions never threw exceptions,=0A=
> and changing to that now is a big BC break, which is not warranted.=0A=
>=0A=
> It was always a deliberate choice (since 2014) that the procedural=0A=
> versions don't throw exceptions, and the OO versions do. The RFC is not=
=0A=
> wanting to change this behaviour. And rightfully so.=0A=
=0A=
Thank you for the clarification. I know that the functions `date_create`=0A=
and `date_create_immutable` have this difference in behavior from the=0A=
`DateTime` and `DateTimeImmutable` constructors, and this is documented=0A=
in the PHP manual.=0A=
=0A=
But for most other date functions there doesn't seem to be any difference.=
=0A=
E.g. `date_create_from_format` and `DateTime::createFromFormat` both return=
=0A=
false on failure.=0A=
=0A=
Likewise, `date_interval_create_from_date_string` and `DateInterval::create=
FromDateString`=0A=
both output a warning and return false on failure, as do `date_modify` and =
`DateTime::modify`.=0A=
See https://3v4l.org/HjXee.=0A=
=0A=
So I'm struggling to understand why it's okay to make a BC break for the OO=
 API,=0A=
but not for the procedural API. As long as a BC break is being made, why no=
t=0A=
change `date_create` and `date_create_immutable` throw exceptions like the=
=0A=
constructors, rather than trying to preserve BC for only the procedural API=
=0A=
and ending up with even more inconsistent behavior?=0A=
=0A=
Best regards,=0A=
Theodore=