Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129801
Precedence: list
MIME-Version: 1.0
Date: Wed, 21 Jan 2026 12:09:55 +0000
Message-ID: <CAGBsUrf2=4SLdfWUUe560Z=0YtSP67xS=QniaiRqABT-WqzfOA@mail.gmail.com>
Subject: [PHP-DEV] Was deprecation of DATE_RFC7231 and DateTimeInterface::RFC7231
 a mistake?
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: tekiela246@gmail.com (Kamil Tekiela)

Hi All,

I was one of the yes-voters for the
https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_date_rfc7231_and_datetimeinterfacerfc7231
however, I would like to change my vote to no now.

The explanation for the deprecation wasn't very clear, and I feel I
was slightly misled by it.  It claims that the constant was
implemented by mistake, but I don't think that was the case.

DATE_RFC7231 follows the timestamp specification from the HTTP format.
It has been repeated by the current RFC 9110
https://www.rfc-editor.org/rfc/rfc9110#section-5.6.7
The GMT part isn't a mistake; it's hardcoded as part of the format.
Thus, the constant is implemented correctly in PHP.

It's true that this could lead to unexpected results when you format a
DateTime that isn't in UTC, but that's a programmer mistake and not
the fault of the constant. The format is timezone agnostic so it's the
responsibility of the programmer to ensure the DateTime object is in
UTC before formatting.

Users are now faced with having to replace the constant with its
string value, despite the constant having a well-defined use and
producing correct and "wanted" results. This is more error-prone than
accidentally forgetting to call setTimezone(DateTimeZone::UTC).
Deprecating this constant hasn't improved anything for PHP users and
only made things worse.

What do you think? Should we undeprecate these constants?

Regards,
Kamil Tekiela