I don't know if this is supposedly already worked out, but I've run into a problem with the future date of 2038.
I'm using php 5.1 with the php4 module installed.

Here is how I came across the issue.
I'm writing a custom module with some cross field validation and ran into this problem comparing two dates.
Here is my code:

// Make sure we're checking real dates here
if(!is_date($node -> field_birthday[0][value]) || !is_date($node -> field_expected_retirement_date[0][value])){
  // If not, we know the dates aren't right, so return an error
  form_set_error('field_expected_retirement_date', t('The year for the expected retirement date should be the birth year + 65'));
}else{// Otherwise, go ahead and check the difference
  $date_diff = date_difference($node -> field_birthday[0][value], $node -> field_expected_retirement_date[0][value], 'years', $type);
  if($date_diff != 65){//check to make sure the date difference is 65
    drupal_set_message($date_diff . " for whatever reason isn't 65", "error");
    //@TODO: fix this so it only highlights the year.
    form_set_error('field_expected_retirement_date', t('The year for the expected retirement date should be the birth year + 65'));
  }
}

Now if I set the birthday to 1975 and the expected retirement date to 2040 (which should be 65) the value returned from the date_difference function is 72.

The date_difference between 1975 and 2038 is a correct 63, but with 2039 is 73 and counts down every year from there.
That means that the date_difference between 1975 and 2047 return 65.

And just some notes about that code in case you were wondering:

$type is declared outside this code where I figure out what format the dates are in.
I had to do this because the validate hook in this custom module is called after the standard validation. If the standard validation passes, the dates are in ISO format. If it doesn't pass, the dates are in array format. Not sure why this is, but I worked around it.

is_date is my own customized version of date_is_valid.

Comments

Gidgidonihah’s picture

Title: Continued problem with 2038 and date_difference function » date_format() and 2038+ don't mix well

Well I narrowed down where the problem comes from.

The date_difference function calls the date_format function (which doesn't exist php<5.2 so it is created in date_php4.inc).
With that call, the timezone is UTC, the year is greater than 1970 and 'Y' isn't a php5 format, so the if statement is true and on line 124 of date_php4.inc the gmdate function is called and given a timestamp greater than 2147483647 which it rolls over and starts counting up from 1901.

So the date_format function needs something like a check

if($timestamp > 2147483647)

and make the appropriate adjustments.

Now the code for those adjustments... well I don't know where to start with that.

Gidgidonihah’s picture

Well, after much frustration and not remembering how things were yesterday (I guess that's what I get for using a -dev version) I've come to the realization that none of my dates after 2038 are working correctly.
They all revert back to 1901+.
Yet all my dates before 1901 work just fine. Go figure.

Here's hoping KarenS can put together a fix.

Gidgidonihah’s picture

Title: date_format() and 2038+ don't mix well » 2038+ is the bane of my existence

Oh, and I suspect a large part of the issue still lies with the date_format function.
Curse you 32bit signed int!

karens’s picture

Status: Active » Fixed

There have been lots and lots of fixes to the PHP4 code since this was reported. I'm assuming it's been fixed since, but you can reopen if not.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.