# Unsure how to handle given Java type \[java.time.LocalDateTime\] as TemporalType#TIMESTAMP when one parameter is reused across several attributes sharing an AttributeConverter

**URL:** <https://discourse.hibernate.org/t/unsure-how-to-handle-given-java-type-java-time-localdatetime-as-temporaltype-timestamp-when-one-parameter-is-reused-across-several-attributes-sharing-an-attributeconverter/12444>\
**Category:** Hibernate ORM\
**Created:** [September 30, 2026, 10:46am UTC](https://discourse.hibernate.org/t/unsure-how-to-handle-given-java-type-java-time-localdatetime-as-temporaltype-timestamp-when-one-parameter-is-reused-across-several-attributes-sharing-an-attributeconverter/12444 "2026-09-30T10:46:27Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![HiMyNameIsIlNano](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/himynameisilnano/32/4394_2.png) [@HiMyNameIsIlNano](https://discourse.hibernate.org/u/HiMyNameIsIlNano)\
**Post date:** [September 30, 2026, 10:46am UTC](https://discourse.hibernate.org/t/unsure-how-to-handle-given-java-type-java-time-localdatetime-as-temporaltype-timestamp-when-one-parameter-is-reused-across-several-attributes-sharing-an-attributeconverter/12444/1 "2026-09-30T10:46:27Z")

</div>

````auto
**Affected versions:** 7.4.0.Final – 7.4.11.Final (latest tested). Works on 7.3.2.Final, so this is a 7.4 regression.

#### Description

I have discovered an issue while developing a library for my company. A JPQL query that compares several entity attributes against **one single named parameter** fails to bind when

* the attributes are mapped with the same `@Convert(converter = ...)`, whose relational type is not one of the types
  `BindingTypeHelper.resolveTimestampTemporalTypeVariant` knows, and
* the parameter is used **three or more times** across **at least two different** such attributes.

For example the following query:

```java
entityManager.createQuery("""
        SELECT r FROM Record r
        WHERE r.validFrom <= :now
          AND r.validTo > :now
          AND r.recordedFrom <= :now
        """, Record.class)
    .setParameter("now", OffsetDateTime.now())
    .getResultList();
```

fails with 

```
java.lang.IllegalArgumentException: Unsure how to handle given Java type [java.time.LocalDateTime]
                                    as TemporalType#TIMESTAMP
    at org.hibernate.type.internal.BindingTypeHelper.resolveTimestampTemporalTypeVariant(BindingTypeHelper.java:144)
    at org.hibernate.type.internal.BindingTypeHelper.resolveBindType(BindingTypeHelper.java:110)
    at org.hibernate.sql.exec.spi.JdbcParameterBindings.createAndAddBinding(JdbcParameterBindings.java:97)
    at org.hibernate.sql.exec.internal.AbstractJdbcParameter.forEachDisassembledJdbcValue(AbstractJdbcParameter.java:184)
    at org.hibernate.metamodel.mapping.Bindable.forEachJdbcValue(Bindable.java:173)
    at org.hibernate.sql.exec.spi.JdbcParameterBindings.registerParametersForEachJdbcValue(JdbcParameterBindings.java:77)
    at org.hibernate.query.sqm.internal.SqmUtil.createValueBindings(SqmUtil.java:724)
    at org.hibernate.query.sqm.internal.SqmUtil.createJdbcParameterBinding(SqmUtil.java:657)
    at org.hibernate.query.sqm.internal.SqmUtil.createJdbcParameterBindings(SqmUtil.java:532)
    ...
```

The mapping looks as follows:

```java
@Converter
public class UtcOffsetConverter implements AttributeConverter<OffsetDateTime, LocalDateTime> { ... }

@Entity
public class Record {
    @Convert(converter = UtcOffsetConverter.class) private OffsetDateTime validFrom;
    @Convert(converter = UtcOffsetConverter.class) private OffsetDateTime validTo;
    @Convert(converter = UtcOffsetConverter.class) private OffsetDateTime recordedFrom;
    @Convert(converter = UtcOffsetConverter.class) private OffsetDateTime recordedTo;
}
```

#### What exactly triggers it

Below is a small table summarising when the exception gets triggered:

| Query | Result |
| --- | --- |
| `validFrom <= :now` | works |
| `validFrom <= :now AND validTo > :now` | works |
| `validFrom <= :now AND validTo > :now AND recordedFrom <= :now` | **fails** |
| `validFrom <= :now AND validTo > :now AND validFrom <= :now` | **fails** |
| `validFrom <= :now` repeated 4× (same attribute) | works |
| `validFrom <= :a AND validTo > :b AND recordedFrom <= :c` | works |

So: **≥ 3 uses AND ≥ 2 distinct attributes.** One attribute repeated any number of times is fine, and splitting the one parameter into several distinct ones is fine.

````

````auto
#### Suggested fix

**Method:** `org.hibernate.query.internal.QueryParameterBindingImpl#areTypesCompatible`

Use equality instead of comparison by identity:

```diff
 private boolean areTypesCompatible(BasicValuedMapping mapping1, BasicValuedMapping mapping2) {
     final JdbcMapping jdbcMapping1 = mapping1.getSingleJdbcMapping();
     final JdbcMapping jdbcMapping2 = mapping2.getSingleJdbcMapping();
     return jdbcMapping1.getJdbcType() == jdbcMapping2.getJdbcType()
- && jdbcMapping1.getValueConverter() == jdbcMapping2.getValueConverter();
+ && Objects.equals( jdbcMapping1.getValueConverter(), jdbcMapping2.getValueConverter() );
 }
```

`AttributeConverterBean` already overrides `equals`/`hashCode` (since 7.3, over
`attributeConverterBean`, `converterJavaType`, `domainJavaType` and `jdbcJavaType`), so two converter beans for the same converter class and the same domain/relational types compare equal.

````

Regards,  
Daniele

---

<div class="post-metadata">

**Author:** ![beikov](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/beikov/32/258_2.png) [@beikov](https://discourse.hibernate.org/u/beikov)\
**Post date:** [October 1, 2026, 11:55am UTC](https://discourse.hibernate.org/t/unsure-how-to-handle-given-java-type-java-time-localdatetime-as-temporaltype-timestamp-when-one-parameter-is-reused-across-several-attributes-sharing-an-attributeconverter/12444/2 "2026-10-01T11:55:51Z")

</div>

Thanks for the report and suggesting a fix. Please create a Jira ticket for this and provide a PR with a test case, and ideally also a fix, against the Hibernate ORM repository. If you can’t do that, please at least attach the reproducer based on our [test case template](https://github.com/hibernate/hibernate-test-case-templates/blob/master/orm/hibernate-orm-7/src/test/java/org/hibernate/bugs/JPAUnitTestCase.java) to the bug ticket.

---

<div class="post-metadata">

**Author:** ![Sjoerd\_van\_der\_Helm](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/sjoerd_van_der_helm/32/4413_2.png) [@Sjoerd\_van\_der\_Helm](https://discourse.hibernate.org/u/Sjoerd_van_der_Helm)\
**Post date:** [October 22, 2026, 7:21am UTC](https://discourse.hibernate.org/t/unsure-how-to-handle-given-java-type-java-time-localdatetime-as-temporaltype-timestamp-when-one-parameter-is-reused-across-several-attributes-sharing-an-attributeconverter/12444/3 "2026-10-22T07:21:02Z")

</div>

We found the same issue in version 7.2.24

---

<div class="post-metadata">

**Author:** ![HiMyNameIsIlNano](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/himynameisilnano/32/4394_2.png) [@HiMyNameIsIlNano](https://discourse.hibernate.org/u/HiMyNameIsIlNano)\
**Post date:** [October 22, 2026, 11:33am UTC](https://discourse.hibernate.org/t/unsure-how-to-handle-given-java-type-java-time-localdatetime-as-temporaltype-timestamp-when-one-parameter-is-reused-across-several-attributes-sharing-an-attributeconverter/12444/4 "2026-10-22T11:33:35Z")

</div>

Hi @Sjoerd_van_der_Helm , I have opened a pull request with the fix here: [HHH-20955 Fix reuse of binding parameter across several attributes by HiMyNameIsIlNano · Pull Request #13704 · hibernate/hibernate-orm · GitHub](https://github.com/hibernate/hibernate-orm/pull/13704). We can only sit and wait. For a simple workaround you might rename one (or more) of the parameters with the same name because the issue triggers starting with three parameters having the same name and sharing the same converter

---

<div class="post-metadata">

**Author:** ![Sjoerd\_van\_der\_Helm](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/sjoerd_van_der_helm/32/4413_2.png) [@Sjoerd\_van\_der\_Helm](https://discourse.hibernate.org/u/Sjoerd_van_der_Helm)\
**Post date:** [October 22, 2026, 12:11pm UTC](https://discourse.hibernate.org/t/unsure-how-to-handle-given-java-type-java-time-localdatetime-as-temporaltype-timestamp-when-one-parameter-is-reused-across-several-attributes-sharing-an-attributeconverter/12444/5 "2026-10-22T12:11:54Z")

</div>

Yes, thats what we are currently doing. But the problem doenst seem to be consistent with 3+ parameters, or I dont have good grasp of the problem yet haha.

What worries me more is how this hasnt triggered a failing regression test on the side of the hibernate team

---

<div class="post-metadata">

**Author:** ![HiMyNameIsIlNano](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/himynameisilnano/32/4394_2.png) [@HiMyNameIsIlNano](https://discourse.hibernate.org/u/HiMyNameIsIlNano)\
**Post date:** [October 22, 2026, 2:27pm UTC](https://discourse.hibernate.org/t/unsure-how-to-handle-given-java-type-java-time-localdatetime-as-temporaltype-timestamp-when-one-parameter-is-reused-across-several-attributes-sharing-an-attributeconverter/12444/6 "2026-10-22T14:27:05Z")

</div>

As far as I can tell there was no regression test covering the change/code. In my case the issue was triggering because I was using the same converter on 5 different OffesetDateaTime fields. If you give me a small reproducer or example of you use case I can try to check whether I can cover your case with a test too.