Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129805
Precedence: list
MIME-Version: 1.0
Date: Wed, 21 Jan 2026 16:10:31 +0100
To: Derick Rethans <derick@php.net>
Cc: Kamil Tekiela <tekiela246@gmail.com>, PHP internals
 <internals@lists.php.net>
Subject: Re: [PHP-DEV] Was deprecation of DATE_RFC7231 and
 DateTimeInterface::RFC7231 a mistake?
In-Reply-To: <4059bd56-127a-2f9b-9fcf-1b875e249c8d@php.net>
References: <CAGBsUrf2=4SLdfWUUe560Z=0YtSP67xS=QniaiRqABT-WqzfOA@mail.gmail.com>
 <4059bd56-127a-2f9b-9fcf-1b875e249c8d@php.net>
Message-ID: <549592dcce097f5efee25e1fcb2e55db@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2026-01-21 15:47, schrieb Derick Rethans:
> 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.

I agree with Derick's entire email, but particularly this part:

Providing some helper constant that requires you to perform an important 
“extra step” with nothing forcing you to perform that extra step and 
where not performing that extra step will result in behavior that is 
subtly incorrect is dangerous API design. The further away from UTC your 
“default timezone” is, the more wrong will the results be. This can have 
significant consequences on the behavior of your application, e.g. 
cookies expiring too soon or too late and confusing HTTP caching 
behavior.

Best regards
Tim Düsterhus