Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120363 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60991 invoked from network); 19 May 2023 20:50:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 May 2023 20:50:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 89573180543 for ; Fri, 19 May 2023 13:50:00 -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.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, 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-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.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 ; Fri, 19 May 2023 13:50:00 -0700 (PDT) Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2ac82912a59so41765201fa.3 for ; Fri, 19 May 2023 13:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684529398; x=1687121398; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=hWQwYEkNNNn1Ht52qRHQT2H/HznO6ok08shVM7+P9es=; b=rwE37lfmNuOwh5HS/nSaEtg+I28B66PbDleztWv/SZgj2qZ3n7DUuhcfPAImwcXZDV u0GmTDFNtvLFjRTVUowpLmz9prnXk/d4rsimEPThLL4FADQYY1ZmBWyl/yX2/JqP4F3n zxCP2VVA1yKjaswJG9b0j6yFJiuUcDX52TZDCLyaysLXpnEbWqeEiOa/5hvx5jB+DkEK lRbp7f1fE/6D3E/kZgapj9O4jMZE9QVzZqds7I2Sb7rgVKASZPmScWkbUOY9WIB30dzd YqLb47sPg/5M+zaOBGrL8K/Z5NQPVjN6pticnw5vZ4/6Y+yMchMauKi3m8fvB9W4x6HF euxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684529398; x=1687121398; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hWQwYEkNNNn1Ht52qRHQT2H/HznO6ok08shVM7+P9es=; b=M94snqAGxwXZS7EgTyA627e5n2edkUjJvjP67zZ96WSaxUE7C05Rv/S57iWRTR98b8 aDCwtZaJ5wRw4LeqEytJ3mofj0dPAzUYPeZjKjjr3JJvNzqUJ02XDNBvLeFCnAmf6koa kKyR0MRBGB7vxbAntsmWlblWNcnm63YDUVmFPUqR3FfOICJtRo/6ZOWFHba9EiEvKmEu t0CyUsRiptC7MwdFIAZpOHVMeQ2auE9O54qLEFTZ9lHRhtHkBSc2pw8QL9Eiq3dKWLz4 xZWSoMxv7kGZv2xUIgBV2ZhDcppCNeut5LeWYSmwNewZglO4qRDtU3h+Uxk+SuEdxzUb MSAA== X-Gm-Message-State: AC+VfDxx2421DjXTTPCrcEyq1S5UscxuP0GusR3LDu/kjELqn7U9gp7c +R0DUabT5DAgVlbjtRc6eMcnmamBDd7h3bMH0OSIZHZSmyU= X-Google-Smtp-Source: ACHHUZ46rlO+bNe7nL36gNGScsPVVsoT8IjdJK86BdjEEx0+JQJjibXySkerIK8eiwqdyhd4rk1ViSllxscDaZvzIec= X-Received: by 2002:a2e:b209:0:b0:2a7:96bd:9eb3 with SMTP id l9-20020a2eb209000000b002a796bd9eb3mr1163416ljm.3.1684529398187; Fri, 19 May 2023 13:49:58 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 19 May 2023 22:49:46 +0200 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000648b9205fc12105f" Subject: Deprecation of the formats DATE_ISO8601 and DATE_RFC7231 From: jorg.sowa@gmail.com (Jorg Sowa) --000000000000648b9205fc12105f Content-Type: text/plain; charset="UTF-8" Hello everyone, I would like to propose the deprecation of the constants DATE_ISO8601, DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231. Arguments for deprecating DATE_ISO8601: - outdated format, standard has been changed while ago - incompatible with format ISO8601_EXPANDED - misleading behavior for developers [1] [2] - doesn't support microseconds [3] - many misunderstandings in the userland [4] [5] 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] 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] It's my first proposition in the PHP Core and I'm not sure if I should suggest it through RFC or normal discussion like this. If I should propose it in RFC then I can prepare it along with PR. Kind regards, Jorg --000000000000648b9205fc12105f--