[BC break] Cannot use string for filtering `DateTime` column

[mskocik]

With this property definition:

/**
 * @property DateTimeImmutable $created
 */ 
class MyEntity extends Entity {}

Following code throws error Modifier %?ldt expects value to be DateTimeInterface, string given.

$myEntityRepository->findBy([
  'created>' => '2025-01-01'
]);

This condition is allowed in v4. I believe this should also be allowed for datetime columns. Especially when it's valid SQL.

/**
 * @property int $myIntProp
 */ 
class MyEntity extends Entity {}

$myEntityRepository->findBy([
  'myIntProp' => '12'
]);

[mskocik]

I can see that overriding mapping for given column to %any fixes the issue and handles strings and date objects correctly. Which has potential disadvantage of converting timezone (not my case).

I understand why are you making types more strict. But is there any change, this issue can be addressed somehow?
What about introducing new DBAL modifier %ldts, which would accept also string by default? Or keeping default %any also for date columns? I know these solutions have disadvantage to allow to enter any (potentially invalid) string.

[hrach]

Let me describe the problem in more detail:

• the property definition @property DateTimeImmutable $created says it is a DateTime (immutable) instance/type. The entity/repository layer "does not know" that the meaning is only a Date (no time)
• generally, we were missing the usage of proper modifiers when calling findBy() methods. The modifiers were properly used to store (insert/update) data but not to look up; this was fixed in collection: use proper modifiers for filtering arguments #572 (it is also a kind of security fix because you can send arbitrary values that would be converted to valid (safe) SQL, though selecting something different, as the type should not be allowed at all)
• from first sight, it seems that the string SHOULD be accepted, as we also accept it as a property value (and it is auto-converted). So I'll look into this to be sure that's happening.
• however, fixing this bug will introduce a new one in your code - auto converting that string will append "current" time - most probably; then "comparison" on the PHP side (when in ArrayCollection) won't strip the time - as it does not know that the underlying storage type is a Date only;
• the best fix would be to use the proper types in PHP - e.g. a Brick. To do so, we should make the extensibility better, and I plan release its support directly at https://github.com/nextras/orm-brick-date-time

[hrach]

I'm working on the possibility of having a DatePropertyWrapper that will handle this on the entity layer. It is still kind of a bc break, but missing its definition should throw on Db conventions init (when detecting a date time on db side), so basically an easy fix.