It's 12.5 years only until the timestamps in PHP on 32bit will not work as expected anymore.
The DateTime[Immutable] classes use 64bit integers internally already but there are still a couple of places where this is an issue in the API due to PHP integer limit:
Based on that I personally would start to deprecate some of the functions and point to the OOP API and allow floating point values as timestamps.
* date() -> DEPRECATE: Use DateTimeImmutable instead
* gmdate() -> DEPRECATE: Use DateTimeImmutable instead
* getdate() -> DEPRECATE: Use DateTimeImmutable instead
* mktime() -> DEPRECATE: Use DateTimeImmutable instead
* gmmktime() -> DEPRECATE: Use DateTimeImmutable instead
* idate() -> DEPRECATE: Use DateTimeImmutable instead
* localtime() -> DEPRECATE: Use DateTimeImmutable instead
* strtotime() -> DEPRECATE: Use DateTimeImmutable instead
* date_sun_info() -> Support timestamp argument as float
* time() -> Allow to return floating point value if out-of-range
* DateTime[Immutable]::getTimestamp() -> Allow to return floating point value if out-of-range
* DateTime[Immutable]::setTimestamp() -> Support timestamp argument as float
* DateTimeZone::getTransitions() -> Support arguments as float and allow resulting transition timestamp as float if out-of-range
Alternatively, zend_long could be migrated to int64_t or arbitrary integers like proposed by Andrea Faulds back in 2014 [1].
Warning: mktime(): Epoch doesn't fit in a PHP integer in /home/mbennewitz/workspace/php-src/y2038.php on line 2
Jan 01 1970 00:00:00
Warning: mktime(): Epoch doesn't fit in a PHP integer in /home/mbennewitz/workspace/php-src/y2038.php on line 3
Jan 01 1970 00:00:00
If you use 32bit version of PHP then of course you will run into this
problem. But 32bit versions are used infrequently now, and this is a
known limitation. As far as I know, these functions have no issues
with year 2038 in 64bit. My point is that these functions work fine
and the fact that 32bit is limited isn't a very good reason to
deprecate them. If anything, it's a reason to deprecate 32bit
versions.
Future dates aren't an alien concept. Applications must already
account for the year 2038 problem today. PHP has handled this issue a
long time ago. If PHP users who use the 32bit version are not ok with
this limitation, then they must make an effort to migrate to 64bit
architecture.
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.
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.
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 ¯\_(ツ)_/¯).
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.
Dropping 32bit builds entirely is an option I would support as well.
Would you be able to help me writing an RFC for it as I don't have enough knowledge of PHP internals to know where 32bit build is going to be problematic there as well?
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".
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>](mailto: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>](mailto: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).
On Mon, Jun 16, 2025 at 4:03 PM Marc Bennewitz <marc@mabe.berlin> wrote:
> It's 12.5 years only until the timestamps in PHP on 32bit will not
> work as expected anymore.
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.
FWIW, I dropped support for 32-bit PHP builds for Xdebug quite a while
ago already:
It's 12.5 years only until the timestamps in PHP on 32bit will not work as
expected anymore.
The DateTime[Immutable] classes use 64bit integers internally already but
there are still a couple of places where this is an issue in the API due to
PHP integer limit:
Based on that I personally would start to deprecate some of the functions and
point to the OOP API and allow floating point values as timestamps.
I think I would agree with deprecating the "really old" date time APIs
as well, but not because of the 2038 problem. However, I also don't
think we should deprecate these before there is a better Date/Time API
in PHP which solves a few of the issues with the current Date/Time
classes and methods. Although they handle the 2038 issue, there are
obviously numerous issues with it (Immutable vs non-Immutable, or not
having dedicated types for timezoned/local dates, and instants, for
example).
->