[PR #8328] Infer datetime_immutable DBAL type for \DateTimeImmutable instance parameters #10923

New Issue

admin · 2026-01-22T16:09:07+01:00

admin commented

2026-01-22 16:09:07 +01:00

Original Pull Request: https://github.com/doctrine/orm/pull/8328

State: closed
Merged: Yes

The support for passing \DateTimeImmutable instance as a query parameter has been added to ORM in #1333 (the year 2015), a long time before immutable date types (datetime_immutable etc) were introduced to DBAL in doctrine/dbal#2450 (2017).

Back then, it made sense to treat \DateTimeImmutable (or any \DateTimeInterface) in the same way as \DateTime and infer parameter type as datetime. However, when immutable date types were later added to DBAL, it wasn't reflected anyhow in type inference in ORM and \DateTimeImmmutable instances are still inferred as datetime DBAL type.

This PR fixes this IMO incorrect behaviour of ParameterTypeInferer::inferType(): for a \DateTimeImmmutable parameter, it now returns datetime_immutable DBAL type; for \DateTime or any other types implementing \DateTimeInterface, it returns datetime DBAL type as it did before.

This behaviour is in line with DateTimeImmutableType handling only \DateTimeImmutable and DateTimeType handling any \DateTimeInterface.

Why? In most cases, it doesn't matter and datetime works for \DateTimeImmutable parameters just fine. But it does matter if using custom implementation of datetime_immutable type like UTCDateTimeImmutableType from simpod/doctrine-utcdatetime. Then the broken type inference is revealed.

This is partially related to #6443, however, this PR isn't about custom DBAL types but about correct type inference for build-in types.

**Original Pull Request:** https://github.com/doctrine/orm/pull/8328 **State:** closed **Merged:** Yes --- The support for passing `\DateTimeImmutable` instance as a query parameter has been added to ORM in #1333 (the year 2015), a long time before immutable date types (`datetime_immutable` etc) were introduced to DBAL in doctrine/dbal#2450 (2017). Back then, it made sense to treat `\DateTimeImmutable` (or any `\DateTimeInterface`) in the same way as `\DateTime` and infer parameter type as `datetime`. However, when immutable date types were later added to DBAL, it wasn't reflected anyhow in type inference in ORM and `\DateTimeImmmutable` instances are still inferred as `datetime` DBAL type. This PR fixes this IMO incorrect behaviour of `ParameterTypeInferer::inferType()`: for a `\DateTimeImmmutable` parameter, it now returns `datetime_immutable` DBAL type; for `\DateTime` or any other types implementing `\DateTimeInterface`, it returns `datetime` DBAL type as it did before. This behaviour is in line with [`DateTimeImmutableType` handling only `\DateTimeImmutable`](https://github.com/doctrine/dbal/blob/2.12.x/lib/Doctrine/DBAL/Types/DateTimeImmutableType.php#L32) and [`DateTimeType` handling any `\DateTimeInterface`](https://github.com/doctrine/dbal/blob/2.12.x/lib/Doctrine/DBAL/Types/DateTimeType.php#L41). Why? In most cases, it doesn't matter and `datetime` works for `\DateTimeImmutable` parameters just fine. But it does matter if using custom implementation of `datetime_immutable` type like `UTCDateTimeImmutableType` from [simpod/doctrine-utcdatetime](https://packagist.org/packages/simpod/doctrine-utcdatetime). Then the broken type inference is revealed. This is partially related to #6443, however, this PR isn't about custom DBAL types but about correct type inference for build-in types.

admin added the pull-request label 2026-01-22 16:09:07 +01:00

admin referenced this issue

2026-01-22 16:14:54 +01:00

[PR #10923] basic-mapping: fix new-line rendered in output #12702

Sign in to join this conversation.