Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127687
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Subject: Re: [PHP-DEV] Year 2038 issue
In-Reply-To: <cbb77988-d6d7-489d-b7fd-09fe5fbff331@app.fastmail.com>
Date: Mon, 16 Jun 2025 19:01:52 +0200
Cc: =?utf-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>,
 Marc Bennewitz <marc@mabe.berlin>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <576B21BE-D5ED-49EB-99D9-731F89DF4DAA@garsi.de>
References: <cbb77988-d6d7-489d-b7fd-09fe5fbff331@app.fastmail.com>
To: Robert Landers <rob@bottled.codes>
From: alwin@garsi.de (Yogarine)


Hi all,

On 16 Jun 2025, at 17:24, Rob Landers <rob@bottled.codes> wrote:
>=20
>=20
>=20
> On Mon, Jun 16, 2025, at 16:54, Alexandru P=C4=83tr=C4=83nescu wrote:
>>=20
>>=20
>>=20
>> On Mon, Jun 16, 2025 at 4:03=E2=80=AFPM Marc Bennewitz =
<marc@mabe.berlin> wrote:
>> Hi all,
>>=20
>> It's 12.5 years only until the timestamps in PHP on 32bit will not =
work=20
>> as expected anymore.
>>=20
>>=20
>> Hi,
>>=20
>> I think that maybe we can already deprecate supporting 32 bit builds.
>> And, maybe with PHP 9, or PHP 10, or with a future version that might =
exist in about 6/7 years, completely drop 32 bits support.
>>=20
>> As far as I checked a bit, all major OSs where PHP could run already =
dropped or will drop support for 32 bits builds.
>> I expect that at some point even the linux kernel will drop support.
>>=20
>> The impacted runtimes will probably be very low.
>>=20
>> --=20
>> Alex
>>=20
>=20
> 100% agree. We are already running out of space on some bitmasks =
(there are a couple with exactly one bit left, or even none in the case =
of GC flags) for 32 bit support.
>=20
> =E2=80=94 Rob

I'm reminded of a recent comment by Derick. He mentioned that usually if =
a function can't be provided on a specific platform or SAPI, that =
function is disabled for that environment specifically. This allows for =
a polyfill to provide an alternative implementation. (e.g. =
`getallheaders()`)

Considering 32-bit builds will not be able to reliable provide the =
`date()` function at some point, what if we deprecate, and later =
disable, these integer date functions on 32-bit builds specifically? =
This would have 0 impact for 64-bit users and provide a means for users =
on legacy or embedded systems to use an alternative implementation (that =
perhaps uses a custom Unix epoch, or numeric strings =C2=AF\_(=E3=83=84)_/=
=C2=AF).

Alwin=