DrupalDateTime (and possibly DateTimePlus) relative comparison is broken in PHP 7.3 using relational operators, but DateTime relative comparison is working as intended

I have a situation when comapring DateTimePlus to DrupalDateTime always yields False. Fine with two DateTimePlus objects.

Being as this is a failure in all versions or php testbot tests this is just the way PHP behaves right? I'm not clear on a compatibility change in 7.3 that would cause this.

I'm also not really sure how we could change the operator behavior since PHP doesn't allow operator overloading. What's the critical break here we need to come up with a solution to? Maybe methods or some helper object to help comparing dates. That's what Carbon does. https://carbon.nesbot.com/docs/#api-comparison

This looks like a wontfix to me.

I doubt behavior changed as a result of PHP version. And if it did, it would be because of property comparison, for which I think it would be plain luck if it worked before.

\DateTime has innate comparison magic since PHP 5.2.2. At this time classes cannot implement their own magic comparison [methods].

When comparing same userland classes, PHP will check properties, but this does not work with instances of different classes. So you're out of luck if you wanted to compare DTT/DTP/DT.

Moving this to a task, we could possibly add a helper to ease comparison per neclimdul's suggestion in #9, but this isn't a critical bug.

I have to say that this is surprising that our wrapper class is less functional than the built-in DateTime class. Helper methods would be much appreciated.

So can we really not use comparison operators with DrupalDateTime? That's quite a setback. There should be a compare method at least. Instead I suppose we have to format it and compare the strings?

@clayfreeman, thanks for pointing this problem out and providing a patch.

This issue is about a problem with PHP 7.3, which is EOL and is not used by a currently supported version of Drupal. Therefore I am closing this issue.

@quietone I don't see any discussion in this issue about whether this is or is not a problem with php 7.4+ or php 8. Maybe it was first reported when php 7.3 was the current version of php. The test coverage provided in the patch would seem useful even if it was not a current problem.

The problem is that the same date with different langcodes will not compare correctly. PHP's built \DateTime does compare properly and if it was the only property on our DateTimePlus objects then they would compare correctly too. But it's not so that don't and there is nothing we can do about this. I do think we should add a compare method to make things simpler...

Something like:

  public function compare(DateTimePlus|\DateTime $datetime2, string $operator): bool {
    if ($datetime2 instanceof DateTimePlus) {
      $datetime2 = $datetime2->dateTimeObject;
    }
    return match ($operator) {
      '<' => $this->dateTimeObject < $datetime2,
      '<=' => $this->dateTimeObject <= $datetime2,
      '>' => $this->dateTimeObject > $datetime2,
      '>=' => $this->dateTimeObject >= $datetime2,
      '==' => $this->dateTimeObject == $datetime2,
      '!=' => $this->dateTimeObject != $datetime2,
    };
  }

One thing that will catch people out is that if the the dates have the same langcode then object comparison will work as a user expects and therefore I'd guess that we see a lot of date comparison in custom and contrib.

There's PHP RFC https://wiki.php.net/rfc/drop_32bit_support to drop some date-functions

I thought the discussion on the mailing list was to not touch the functions and just drop the 32bit support