Date validator problem vant validate big unix timestamps

[svycka]

fixes #6352

[svycka]

not sure about tests maybe someone can help?

[samsonasik]

ping @DASPRiD

[Ocramius]

Does this affect the outcome?

[svycka]

yes in 32-bit 999,999,999,999 was converted to 2,147,483,647 when casting to double. you can see the examples in this issue: #6352

[Ocramius]

Wondering if gmp can help here... is the value already broken when leaving the data-provider?

[weierophinney]

I read this entirely wrong; this test uncomments a test set. We're covered, and verified this passes.

[weierophinney]

My notes:

• The test was commented out because the contributor is using a 32-bit architecture, and that test failed due to int -> float conversion.
• The referenced issue essentially asks if the framework should act the same on 32- vs 64-bit architectures.
• Our own continuous integration uses 64-bit architectures.

My take is: no, the framework should not handle this detail. The reason is that the value passed as a timestamp to DateTime must be an integer for reliable results.

This means we cannot pass a string (e.g., for use with bcmath) or GMP instance and expect reliable results. At the same time, we need to test sufficiently large numbers in order to verify everything works as expected.

My take would be to test using PHP_INT_MAX, which will vary based on architecture; we can then change expectations based on architecture (using PHP_INT_SIZE, which will be 4 on 32-bit and 8 on 64-bit).

[weierophinney]

Merged to develop for release with 2.4.