Re: Year 2038 issue

Hi all, On 16 Jun 2025, at 17:24, Rob Landers <rob@bottled.codes> wrote: > > > > On Mon, Jun 16, 2025, at 16:54, Alexandru Pătrănescu wrote: >> >> >> >> On Mon, Jun 16, 2025 at 4:03 PM Marc Bennewitz <marc@mabe.berlin> wrote: >> Hi all, >> >> It's 12.5 years only until the timestamps in PHP on 32bit will not work >> as expected anymore. >> >> >> Hi, >> >> 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. >> >> 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. >> >> The impacted runtimes will probably be very low. >> >> -- >> Alex >> > > 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. > > — 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 ¯\_(ツ)_/¯). Alwin