Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Year 2038 issue »

Year 2038 issue

php.internals

Marc

1 year ago
Hi all, 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]. What do you think? [1] https://wiki.php.net/rfc/bigint

Alain Williams

1 year ago
On Mon, Jun 16, 2025 at 03:01:00PM +0200, Marc Bennewitz wrote:
> Alternatively, zend_long could be migrated to int64_t or arbitrary integers > like proposed by Andrea Faulds back in 2014 >
> What do you think? >
https://wiki.php.net/rfc/bigint +1
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>

Kamil Tekiela

1 year ago
Why do you say that these functions do not work with year 2038? https://3v4l.org/61VLh I wouldn't be opposed to deprecating them, but I don't know if we have a good enough reason to do so.

Wim Godden

1 year ago
Including the EOL versions on that link shows that this occurs on < 5.2.6 only On 16/06/2025 16:16, Kamil Tekiela wrote:

Marc

1 year ago
On 16.06.25 16:16, Kamil Tekiela wrote:
> Why do you say that these functions do not work with year 2038? > https://3v4l.org/61VLh > > I wouldn't be opposed to deprecating them, but I don't know if we have > a good enough reason to do so. >
https://3v4l.org seems to be 64bit now ;) -> https://3v4l.org/1FX4E I get this: $ ./sapi/cli/php y2038.php 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

Kamil Tekiela

1 year ago
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.

Alexandru Pătrănescu

1 year ago
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

Rob Landers

1 year ago
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

Alwin Garside

1 year ago
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

Marc

1 year ago
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".

Rob Landers

1 year ago
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

Marc

1 year ago
On 16.06.25 17:21, Rob Landers 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.
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?

Derick Rethans

1 year ago
On Mon, 16 Jun 2025, Alexandru Pătrănescu wrote:
> 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: https://github.com/xdebug/xdebug/commit/0a6df4d49ddb5a252628668661313e022941779a I have not heard complaints. cheers, Derick

Derick Rethans

1 year ago
Hi, On Mon, 16 Jun 2025, Marc Bennewitz wrote:
> 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). cheers, Derick