Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127723
Date: Thu, 19 Jun 2025 14:16:08 +0100 (BST)
To: Marc Bennewitz <marc@mabe.berlin>
cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Year 2038 issue
In-Reply-To: <4093d14a-8e53-4843-9a07-c7f1d1f339c5@mabe.berlin>
Message-ID: <736d42c5-04cd-d009-9be9-b3706a1cbe8c@php.net>
References: <4093d14a-8e53-4843-9a07-c7f1d1f339c5@mabe.berlin>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: derick@php.net (Derick Rethans)

Hi,

On Mon, 16 Jun 2025, Marc Bennewitz wrote:

> It's 12.5 years only until the timestamps in PHP on 32bit will not work as
> expected anymore.
> 
> The DateTime[Immutable] classes use 64bit integers internally already but
> there are still a couple of places where this is an issue in the API due to
> PHP integer limit:
> 
> Based on that I personally would start to deprecate some of the functions and
> point to the OOP API and allow floating point values as timestamps.

I think I would agree with deprecating the "really old" date time APIs 
as well, but not because of the 2038 problem. However, I also don't 
think we should deprecate these before there is a better Date/Time API 
in PHP which solves a few of the issues with the current Date/Time 
classes and methods. Although they handle the 2038 issue, there are 
obviously numerous issues with it (Immutable vs non-Immutable, or not 
having dedicated types for timezoned/local dates, and instants, for 
example).

cheers,
Derick