Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120402 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 64832 invoked from network); 26 May 2023 10:17:34 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 May 2023 10:17:34 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 56DE7180340 for ; Fri, 26 May 2023 03:17:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_NEUTRAL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS30827 82.113.144.0/20 X-Spam-Virus: No X-Envelope-From: Received: from xdebug.org (xdebug.org [82.113.146.227]) by php-smtp4.php.net (Postfix) with ESMTP for ; Fri, 26 May 2023 03:17:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 430CF10C4E4; Fri, 26 May 2023 11:17:33 +0100 (BST) Date: Fri, 26 May 2023 11:17:33 +0100 (BST) To: Jorg Sowa cc: PHP internals In-Reply-To: Message-ID: <25c841b2-d179-ba8d-d452-d0cdd28363d8@php.net> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-921748391-1685096253=:14284" Subject: Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231 From: derick@php.net (Derick Rethans) --8323329-921748391-1685096253=:14284 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 19 May 2023, Jorg Sowa wrote: > I would like to propose the deprecation of the constants DATE_ISO8601, > DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231. =E2=80=A6 > In my opinion the question is not whether this constant should be > deprecated, but when. I know that the problem was discussed in the past, > but I hope enough time has passed already to touch this topic again > although of the BC nature. [6] > [7] In my opinion, deprecating this does not do anything besides annoying=20 users. > > Arguments for deprecating DATE_RFC7231: > - error prone nature, the format never really supported timezone. I'm not > sure how it appeared in the code, but tests clearly lack cases for this > format. I'm not sure if it was missed on purpose, but with tests it would > be obvious that the format shouldn't ever appear in the core. [8] > [9] > This should instead be fixed of being deprecated. It is a recent=20 addition after all. cheers, Derick --8323329-921748391-1685096253=:14284--