Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127709
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 18 Jun 2025 14:58:23 +0200
To: internals@lists.php.net
Message-ID: <d07aeeeb-69d3-4ac0-a3cc-a3f0b34a80a2@app.fastmail.com>
In-Reply-To: <4b5da64c-36b9-49db-8ec4-3247e05bf286@mabe.berlin>
References: <cbb77988-d6d7-489d-b7fd-09fe5fbff331@app.fastmail.com>
 <576B21BE-D5ED-49EB-99D9-731F89DF4DAA@garsi.de>
 <4b5da64c-36b9-49db-8ec4-3247e05bf286@mabe.berlin>
Subject: Re: [PHP-DEV] Year 2038 issue
Content-Type: multipart/alternative;
 boundary=4530c7447db5419d94ac5b11ef7e8bf1
From: rob@bottled.codes ("Rob Landers")

--4530c7447db5419d94ac5b11ef7e8bf1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 18, 2025, at 13:18, Marc Bennewitz wrote:
>=20
>=20
> On 16.06.25 19:01, Yogarine wrote:
>> Hi all,
>>=20
>> On 16 Jun 2025, at 17:24, Rob Landers <rob@bottled.codes> wrote:
>>> On Mon, Jun 16, 2025, at 16:54, Alexandru P=C4=83tr=C4=83nescu wrote:
>>>> On Mon, Jun 16, 2025 at 4:03=E2=80=AFPM Marc Bennewitz <marc@mabe.b=
erlin> 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 build=
s.
>>>> And, maybe with PHP 9, or PHP 10, or with a future version that mig=
ht 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 alread=
y 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
>>> 100% agree. We are already running out of space on some bitmasks (th=
ere 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 fu=
nction is disabled for that environment specifically. This allows for a =
polyfill to provide an alternative implementation. (e.g. `getallheaders(=
)`)
>>=20
>> Considering 32-bit builds will not be able to reliable provide the `d=
ate()` function at some point, what if we deprecate, and later disable, =
these integer date functions on 32-bit builds specifically? This would h=
ave 0 impact for 64-bit users and provide a means for users on legacy or=
 embedded systems to use an alternative implementation (that perhaps use=
s a custom Unix epoch, or numeric strings =C2=AF\_(=E3=83=84)_/=C2=AF).
> It's a long list of date functions already (see my first mail) and on =
looking deeper into detail it's not limited to the date extension. Same =
issues happen on a wide range of standard functions like "filemtime" or =
"opcache_get_status". Specifically everywhere where a timestamp is invol=
ved. Not even talking about the already known behavior differences of fu=
nctions like "crc32".
>=20
>=20
>=20
>> Alwin
>=20
> *Attachments:*
>  =E2=80=A2 OpenPGP_0x3936ABF753BC88CE.asc
>  =E2=80=A2 OpenPGP_signature.asc

I dunno. The more I think about it, the more this seems like a systemic =
issue with 32-bit. Meaning this is potentially the wrong layer to try an=
d fix it. This will likely have to be addressed at a deeper layer (such =
as the OS) or a higher layer (treating negative numbers differently than=
 positive ones, contextually).

=E2=80=94 Rob
--4530c7447db5419d94ac5b11ef7e8bf1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Wed, Jun =
18, 2025, at 13:18, Marc Bennewitz wrote:</div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><p><br></p><div class=3D"qt-moz-cite-prefix">On 16=
.06.25 19:01, Yogarine wrote:</div><blockquote type=3D"cite" cite=3D"mid=
:576B21BE-D5ED-49EB-99D9-731F89DF4DAA@garsi.de"><pre class=3D"qt-moz-quo=
te-pre">Hi all,=0A=0AOn 16 Jun 2025, at 17:24, Rob Landers <a class=3D"q=
t-moz-txt-link-rfc2396E" href=3D"mailto:rob@bottled.codes">&lt;rob@bottl=
ed.codes&gt;</a> wrote:=0A</pre><blockquote type=3D"cite"><pre class=3D"=
qt-moz-quote-pre">On Mon, Jun 16, 2025, at 16:54, Alexandru P=C4=83tr=C4=
=83nescu wrote:=0A</pre><blockquote type=3D"cite"><pre class=3D"qt-moz-q=
uote-pre">On Mon, Jun 16, 2025 at 4:03=E2=80=AFPM Marc Bennewitz <a clas=
s=3D"qt-moz-txt-link-rfc2396E" href=3D"mailto:marc@mabe.berlin">&lt;marc=
@mabe.berlin&gt;</a> wrote:=0AHi all,=0A=0AIt's 12.5 years only until th=
e timestamps in PHP on 32bit will not work=20=0Aas expected anymore.=0A=0A=
=0AHi,=0A=0AI think that maybe we can already deprecate supporting 32 bi=
t builds.=0AAnd, maybe with PHP 9, or PHP 10, or with a future version t=
hat might exist in about 6/7 years, completely drop 32 bits support.=0A=0A=
As far as I checked a bit, all major OSs where PHP could run already dro=
pped or will drop support for 32 bits builds.=0AI expect that at some po=
int even the linux kernel will drop support.=0A=0AThe impacted runtimes =
will probably be very low.=0A=0A--=20=0AAlex=0A=0A</pre></blockquote><pr=
e class=3D"qt-moz-quote-pre">100% agree. We are already running out of s=
pace 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.=0A=0A=E2=80=94 Rob=
=0A</pre></blockquote><pre class=3D"qt-moz-quote-pre">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 fo=
r that environment specifically. This allows for a polyfill to provide a=
n alternative implementation. (e.g. `getallheaders()`)=0A=0AConsidering =
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 d=
ate functions on 32-bit builds specifically? This would have 0 impact fo=
r 64-bit users and provide a means for users on legacy or embedded syste=
ms to use an alternative implementation (that perhaps uses a custom Unix=
 epoch, or numeric strings =C2=AF\_(=E3=83=84)_/=C2=AF).</pre></blockquo=
te><p>It's a long list of date functions already (see my first mail)=0A =
     and on looking deeper into detail it's not limited to the date=0A  =
    extension. Same issues happen on a wide range of standard=0A      fu=
nctions like "filemtime" or "opcache_get_status". Specifically=0A      e=
verywhere where a timestamp is involved. Not even talking about=0A      =
the already known behavior differences of functions like "crc32".</p><p>=
<span style=3D"white-space-collapse:preserve;text-wrap-mode:wrap;"></spa=
n><br></p><blockquote type=3D"cite" cite=3D"mid:576B21BE-D5ED-49EB-99D9-=
731F89DF4DAA@garsi.de"><pre class=3D"qt-moz-quote-pre">Alwin=0A</pre></b=
lockquote><div><br></div><div><b>Attachments:</b></div><ul><li>OpenPGP_0=
x3936ABF753BC88CE.asc</li><li>OpenPGP_signature.asc</li></ul></blockquot=
e><div><br></div><div>I dunno. The more I think about it, the more this =
seems like a systemic issue with 32-bit. Meaning this is potentially the=
 wrong layer to try and fix it. This will likely have to be addressed at=
 a deeper layer (such as the OS) or a higher layer (treating negative nu=
mbers differently than positive ones, contextually).</div><div><br></div=
><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--4530c7447db5419d94ac5b11ef7e8bf1--