DateTimeImmutable fields with Types::DATE_IMMUTABLE suddenly include time component in DQL comparisons

[steinwandnick]

Problem Summary

After updating to doctrine-extensions 3.20.0, date comparisons in DQL queries no longer work as expected. Date values of type Types::DATE_IMMUTABLE now include a time component during queries, causing previously working comparisons to fail. I guess before it was handled as 2025-04-14 00:00:00 and now as 2025-04-14 17:33:12 (current time, while i was writing this issue).

Steps to Reproduce

A simple comparison like the following no longer works as expected:

// f.dueDate = '2025-04-04'
// today = '2025-04-14' (+ 10 days)
->andWhere("DATE_ADD(f.dueDate, :dueDays, 'day') <= :today")
->setParameter('today', $this->today->format('Y-m-d'))
->setParameter('dueDays', 10)

Where f.dueDate is defined as Types::DATE_IMMUTABLE in the entity:

#[ORM\Column(type: Types::DATE_IMMUTABLE, nullable: true)]
private ?DateTimeImmutable $dueDate = null;

Expected Behavior

The comparison should only consider the date part and ignore the time component, as it did in version 3.19.x.

Actual Behavior

The comparison now also considers the time component, even though the field is defined as Types::DATE_IMMUTABLE. This causes certain comparisons to fail that were working before.

Workaround

As a workaround, I had to explicitly account for the time component:

->setParameter('today', $this->today->setTime(23, 59, 59)->format('Y-m-d H:i:s'))

Environment

doctrine/orm version: 3.3.2 / 3.4
doctrine-extensions version: 3.20.0 (previously 3.19.0)
PHP version: 8.4

Additional Information

The issue occurred immediately after updating to doctrine-extensions 3.20.0. The code was working fine before. It seems that the changes related to support for Doctrine ORM 3.4, particularly the adjustments to propertyAccessors vs. reflFields, may have led to a change in behavior when handling DATE_IMMUTABLE types.

[mbabker]

I'm not quite following how that change impacts your code? Nothing in your example uses features from this package. If you're sure it's related to #2934 then can you provide a more complete example where the tree extension is in use?

[steinwandnick]

I'm not quite following how that change impacts your code? Nothing in your example uses features from this package. If you're sure it's related to #2934 then can you provide a more complete example where the tree extension is in use?

You’re right, the only change I had made was updating from 3.19 to 3.20, so I started analyzing at this point. However, after further analysis, it turned out that this wasn’t the cause after all. The issue here is really tricky. I was surprised as well.

Thanks anyway for the quick reply!