Year 2038 issue

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

Attachment: [application/pgp-keys] OpenPGP public key OpenPGP_0x3936ABF753BC88CE.asc
Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc