0

Am using the strtotime function to find the difference between two given dates like this:

$diff_in_mill_seconds = strtotime($ToDate) - strtotime($FromDate);
$difference_in_years = round($diff_in_mill_seconds / (365*60*60*24),1);

This script fails when the $ToDate is beyond 2038-01-19.

The official PHP Documentation says:

The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC

The PHP Documentation also says:

Using this function for mathematical operations is not advisable. It is better to use DateTime::add() and DateTime::sub() in PHP 5.3 and later, or DateTime::modify() in PHP 5.2.

I cannot use DateTime::add() and DateTime::sub() as the PHP version on the server is 5.2.

So, how do I calculate the difference between two dates (beyond 2038-01-19) in years using php 5.2?

Prashanth JC
  • 537
  • 1
  • 6
  • 20
  • [This answer](http://stackoverflow.com/a/3266088/862594) confirms my intuition - The UNIX timestamp is rolling over because you're on a 32-bit machine. Switch to a 64-bit machine and you'll be able to represent dates greater than 2038 as a UNIX timestamp. – nickb Apr 10 '13 at 03:12
  • PHP 5.2 *and* not a 64bit machine? Sorry, nothing can help you. You simply need a newer version of *something*. – deceze Apr 10 '13 at 03:13
  • @Sabari `DateTime::add` specifically was introduced in 5.3. – deceze Apr 10 '13 at 03:14
  • I have answered it here : http://stackoverflow.com/questions/2012589/php-mysql-year-2038-bug-what-is-it-how-to-solve-it/38394845#38394845 – Venkatesh GS Rao Jul 15 '16 at 13:21

1 Answers1

1

It's the UNIX Y2K38 bug. It has been fixed in 64bit implementations of PHP or by using DateTime::diff, which does not use integers internally and hence does not suffer from the problem.

You need either. There's no real fix without switching platforms.

deceze
  • 510,633
  • 85
  • 743
  • 889