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?
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
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.
Including the EOL versions on that link shows that this occurs on <
5.2.6 only
Why do you say that these functions do not work with year 2038?
https://3v4l.org/61VLhI wouldn't be opposed to deprecating them, but I don't know if we have
a good enough reason to do so.
Why do you say that these functions do not work with year 2038?
https://3v4l.org/61VLhI 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
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.
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
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
Hi all,
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.
--
Alex100% 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
Hi all,
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.
--
Alex100% 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
Hi all,
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.
--
Alex100% 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
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.
--
Alex100% 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?
— Rob
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
Hi,
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