Status: reviewed

👍

👍

This seems to be a issue in linux not in this component. In my opinion, this should be reverted, as PHP_INT_MAX is effectively cache forever whereas the new code defaults to one year.

vagrant@RMBP-015-vagrant:/tmp/foo$ php -a
Interactive mode enabled

php > touch('/tmp/foo/foo-test', pow(2, 55));
php > touch('/tmp/foo/foo-test2', pow(2, 56));
php > exit
vagrant@RMBP-015-vagrant:/tmp/foo$ ls -la
total 8
drwxrwxr-x 2 vagrant vagrant 4096 Jul 31 19:44 ./
drwxrwxrwt 6 root    root    4096 Jul 31 19:43 ../
-rw-rw-r-- 1 vagrant vagrant    0 Jun 13  1141709097 foo-test
-rw-rw-r-- 1 vagrant vagrant    0 72057594037927936 foo-test2

If I had to make any guesses, I'll bet this happens when the year's representation can no longer fit into a 32 bit integer.

EDIT: according to the article on the 2038 problem. I was close. It's 2^32 + 1900.

Most operating systems designed to run on 64-bit hardware already use signed 64-bit time_t integers. Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 on Sunday, 4 December 292,277,026,596. The ability to make computations on dates is limited by the fact that tm_year uses a signed 32 bit int value starting at 1900 for the year. This limits the year to a maximum of 2,147,485,547 (2,147,483,647 + 1900).