Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120464 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 61052 invoked from network); 30 May 2023 16:26:54 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 May 2023 16:26:54 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 62903180384 for ; Tue, 30 May 2023 09:26:53 -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=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,MISSING_HEADERS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 30 May 2023 09:26:53 -0700 (PDT) Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-565a6837a0bso62251627b3.3 for ; Tue, 30 May 2023 09:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685464012; x=1688056012; h=content-transfer-encoding:cc:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DnjtHXLHY9iU+HkESZio0tlRHESfhEXnf6Zvmf2yjT8=; b=jkhyPD1jaIB9awWwYzGHDCMMCcJ12hVQaGkmGFnuMm/M2axUYzmx5/BV5BUuO4FAV5 LFbfdxoIydaBhTHReaPZ+kON0EWsprnDjPrOUwlSjXDsEa4PhcInvvgrK0pbysGbw65Q gv4BRcBTaRhpYV4vN2eTwkUWr7w36A93yDY+7VG6DngQskmoMOMByP/3eHJUW7erNycf 9cTeUQ6AWQm289Q/LPAo+MFCLpjmae+um4FrJZiVZzYcppfAQ5UHXr+MnKsbZY+zaHsu ZD6EfLvW6lC2TENPqoqCQpPsoGRKdkWuQyhKCI/TOjiDfIcCUednkMvDFw2qw2cDAiun vWBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685464012; x=1688056012; h=content-transfer-encoding:cc:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DnjtHXLHY9iU+HkESZio0tlRHESfhEXnf6Zvmf2yjT8=; b=lx7HeaIpeDAFKvVBp/zv0ZjB+P+a4IT1w9A4qMjc2Nai1ObErsaO1NS6E1rJlPfIFs hzYalz0kunJ/qKKVYd6pc0SnGFa3cDOC2NIQjIZ+Nq3rxuea/egljUAGQx6mURPHRx1m il6wk5rOOBmknWKa/wV1BeJ8Hed/NYDfJFRjIKGdM5LlFT+95PhbA9FrYSa+0dwBgyno wyO25dAwk56gWQKfwkSPWKw87rmxMat16Nvr/Vhx/y01M08nM7sEJmv1i7q/ZKAf4PkO D4WbkvAlRcy1nAyJZQV4Lc786bwT3ZkqIHRmhcSVn8b6dvchklzBvVfXgfsv3CDYyYsY ripg== X-Gm-Message-State: AC+VfDwo8u9iy0QV98InoVDWp4zd7TWsr+JNmdyblAKr7vnkWIzUXdkn fVm6FHkdhunrLNTfN5yly/17WU/x7yp52I8cBP3nrAwZmYBTDQ== X-Google-Smtp-Source: ACHHUZ5oZe1YQO/65L63Hp23DV33PVJtwv6UDZ0d+ajQZhbK9sBKXNho8SJ1wAAFMfEs0tdSyErFmQU8DSsvcyKs4Ns= X-Received: by 2002:a81:4687:0:b0:568:d9a5:b361 with SMTP id t129-20020a814687000000b00568d9a5b361mr1488912ywa.16.1685464012291; Tue, 30 May 2023 09:26:52 -0700 (PDT) MIME-Version: 1.0 References: <25c841b2-d179-ba8d-d452-d0cdd28363d8@php.net> In-Reply-To: <25c841b2-d179-ba8d-d452-d0cdd28363d8@php.net> Date: Tue, 30 May 2023 18:26:14 +0200 Message-ID: Cc: PHP internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231 From: divinity76@gmail.com (Hans Henrik Bergan) >In my opinion, deprecating this does not do anything besides annoying users. In my opinion, since it isn't, and likely never was, a legal ISO8601 string, it's a no-brainer that it should be deprecated. (it's at least been illegal since iso8601:2004 released in 2004) On Fri, 26 May 2023 at 12:17, Derick Rethans wrote: > > 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 > users. > > > > > Arguments for deprecating DATE_RFC7231: > > - error prone nature, the format never really supported timezone. I'm n= ot > > 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 wou= ld > > 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 > addition after all. > > cheers, > Derick > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php