-1

I am coding a project where the dates in the future can be quite a ways in the future. In the project, the number of days ahead is css colored green, behind (today) is coded red and if it is today colored white.

The bulk of the code is below.

     $dtAsString = "9/18/2037"
     $dueDate    = new DateTime($dtAsString);

        //0 day calculation
            if ( $dueDate->diff(new DateTime())->days == 0 )
            {
                //white
                $css = "white";
                return 0;
            }

        //if not in past, green, otherwise red
            //die("date=" . $dtAsString . " past:'" . (strtotime( $dueDate ) < time() )  . "' CALC: " . $dueDate->diff()->days);
        if ( ( time() < strtotime( $dtAsString ) ) == 1  )
        {
            //less than today is green
            $css = "green";
            return $dueDate->diff(new DateTime())->format("%a") * -1;

        } else {
            //after due date is red
            $css = "red";
            return $dueDate->diff(new DateTime())->format("%a");
        }

If $dtAsString is 9/18/37 it comes back correctly as ahead of today and colored green. However, if I move the year up to 9/1/2097 it is no longer in the future and returns as red. I originally thought this was an error with the custom date class I was using. But since I removed the date class and am using the raw PHP date objects, I still get the same result.

Has anyone else run into this? Any assistance is very much appreciated.

EDIT 1:35 pm 5/27/2021

In researching PHP's strtotime(), I can confirm it has to do with the fact I am using x86 vs x64. On my test machine it is x86. And because occasionnally I have to use MS ACCESS which library typically is x86 (even though accdb is 64), so is my production system.

Thank you all for your support and quick responses. As I am new to Stackoverflow, I cannot as yet mark any answer as correct or even upvote. But thank you all!

  • 3
    Apparently it [depends on if the system is affected by the Y2k38 bug](https://en.wikipedia.org/wiki/Year_2038_problem) – aynber May 27 '21 at 17:14
  • Does this answer your question? [Maximum time() | PHP](https://stackoverflow.com/questions/3953333/maximum-time-php) – Russ J May 27 '21 at 17:16
  • Which version of PHP, which flavour of which OS, etc? Because PHP7's DateTime allows years as early as 0000 and as late as 9999 (but they _need_ to be four digit years. Just saying `9/1/0` means you're implying `9/1/2000`) – Mike 'Pomax' Kamermans May 27 '21 at 17:18
  • See https://stackoverflow.com/questions/5319710/accessing-dates-in-php-beyond-2038 – Chris Lear May 27 '21 at 17:19
  • @ChrisLear but they're already using DateTime? – Mike 'Pomax' Kamermans May 27 '21 at 17:25
  • Probably just `if ( new DateTime() < $dueDate ) {` instead of `strtotime`. – AbraCadaver May 27 '21 at 17:26
  • @Mike'Pomax'Kamermans Not in the `if` condition. – AbraCadaver May 27 '21 at 17:27
  • No, diff works fine, too. http://sandbox.onlinephpfunctions.com/code/e6d63d5040f6c99d841fca1a4a8f98df760b3e72 shows this doing exactly what it should be, with years _well_ above 2038. – Mike 'Pomax' Kamermans May 27 '21 at 17:27
  • @AbraCadaver, ah "use DateTime all the way through". Not sure this counts as dupe, an answer showing that they should just use the value their code is _already calculating_ (note their code that counts the days between now and the future DateTime). Capture `$days = ...;` and then check if that's <0, ==0, or >0. – Mike 'Pomax' Kamermans May 27 '21 at 17:31
  • 2
    @Mike'Pomax'Kamermans Well, they use `strtotime` in the `if` which is the problem, so using `DateTime` is the solution. – AbraCadaver May 27 '21 at 17:33
  • Certainly, but it's not so much "use DateTime" as it is "don't use non-DateTime code when you're already using DateTime" (same result, but crucially, a different lesson) – Mike 'Pomax' Kamermans May 27 '21 at 18:26

1 Answers1

0

You need to use a 64-bit version of PHP, otherwise

times beyond 03:14:07 UTC on Tuesday, 19 January 2038 will 'wrap around' and be stored internally as a negative number, which these systems will interpret as a time in December 13, 1901 rather than in 2038.

or consider using the DateTime API, e.g.

$dt = new DateTime('1st February 2999');
echo $dt->format('Y-m-d H:i:s'); // 2999-02-01 00:00:00
dave
  • 62,300
  • 5
  • 72
  • 93
  • Correct. As you see in the code I did indeed use the DateTime API. However, the check for whether the date was in the future used the `strtotime()` and that is wear I ran into the x86 limitation it appears. At least, when I did the research on the different functions I was using. Which displayed almost to the day the issue I was having as I had narrowed it down to the date in the OP. Much appreciate your comments and timely response to all! – Heath Bruce May 28 '21 at 11:57