Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129803
Date: Wed, 21 Jan 2026 14:47:54 +0000 (GMT)
To: Kamil Tekiela <tekiela246@gmail.com>
cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Was deprecation of DATE_RFC7231 and DateTimeInterface::RFC7231
 a mistake?
In-Reply-To: <CAGBsUrf2=4SLdfWUUe560Z=0YtSP67xS=QniaiRqABT-WqzfOA@mail.gmail.com>
Message-ID: <4059bd56-127a-2f9b-9fcf-1b875e249c8d@php.net>
References: <CAGBsUrf2=4SLdfWUUe560Z=0YtSP67xS=QniaiRqABT-WqzfOA@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: derick@php.net (Derick Rethans)

Hi,

On Wed, 21 Jan 2026, Kamil Tekiela wrote:

> 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.

No, it wasn't. It would format according to local time and just add 
"GMT" to the end: 
https://www.php.net/manual/en/class.datetimeimmutable.php (docs haven't 
been updated for it).

> 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.

Formatters are *only* for local time, and do not currently have the 
possibility to change the timezone to UTC. So I disagree, as people 
rightfully should have expected PHP to handle a specific pre-cooked 
format to behave as the RFC that is named after ought to behave.

> 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?

No, I don't believe we should put them back as they were.

I can think of two possible ways:

1. We could think about adding specific formatting *methods*, such as 
   "asRfc7231String()".

   This would allow for it to handle the timezone "fix" and also return the
   right format. Constants aren't the way forwards here. But that also means,
   that we probably should have methods for other useful formats /
   specifications too.

2. Create a new formatting specifier which has a specfic meaning to set the
   timezone to UTC when used at the beginning of the string, say "-".

   There is some precedent with special formatting letters with
   DateTimeImmutable::createFromFormat.

   The constant value then could be "-D, d M Y H:i:s \\G\\M\\T"

I don't really like either of these though.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social