On Wed, Jun 18, 2025, at 13:18, Marc Bennewitz wrote: > > > On 16.06.25 19:01, Yogarine wrote: >> 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 ¯\_(ツ)_/¯). > 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 involved. > Not even talking about the already known behavior differences of functions > like "crc32". > > > >> Alwin > > *Attachments:* > • OpenPGP_0x3936ABF753BC88CE.asc > • 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 and 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). — Rob
