Re: Year 2038 issue

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