本文详解 Joda-Time 的 DateTime 对象在 JDBC 查询中作为参数传递时，因 PostgreSQL 驱动无法自动推断 SQL 类型而抛出异常的根本原因，并提供兼容性更强的解决方案（如改用 minusMonths()、显式类型声明或升级至 JSR-310）。
本文详解 joda-time 的 `datetime` 对象在 jdbc 查询中作为参数传递时，因 postgresql 驱动无法自动推断 sql 类型而抛出异常的根本原因，并提供兼容性更强的解决方案（如改用 `minusmonths()`、显式类型声明或升级至 jsr-310）。
在使用 Joda-Time 的 DateTime 类型配合 Hibernate/JPA 与 PostgreSQL 进行数据库操作时，开发者常遇到如下典型异常：
nested exception is org.postgresql.util.PSQLException: Can't infer the SQL type to use for an instance of org.joda.time.DateTime. Use setObject() with an explicit Types value to specify the type to use.
该错误并非源于 minusDays() 方法本身（它逻辑完全正确），而是 JDBC 驱动在参数绑定阶段对 DateTime 实例的类型映射失败。虽然 DateTime.now() 在某些上下文中（如实体字段初始化或特定 ORM 配置下）能被 jadira-usertype 自动识别为 TIMESTAMP WITH TIME ZONE，但经过 minusDays(60) 计算后生成的新 DateTime 实例，在部分驱动版本或参数传递路径（如 NamedParameterJdbcTemplate 或原生 PreparedStatement）中可能丢失类型上下文，导致 PostgreSQL JDBC 驱动无法安全推断其对应 SQL 类型（Types.TIMESTAMP 或 Types.TIMESTAMP_WITH_TIMEZONE）。
值得注意的是，问题中“改用 minusMonths(2) 后正常”这一现象具有误导性——它并非因为 minusMonths() 有特殊类型处理，而更可能是偶然绕过了某个触发类型推断失败的边界条件（例如时区偏移计算差异、内部毫秒值对齐、或与特定数据库函数交互的缓存行为）。这种“修复”不具备可复现性与可维护性，不应作为正式解决方案。
✅ 推荐的稳健实践如下：
1. 显式指定 JDBC 类型（最直接有效）
若使用 JdbcTemplate 或 NamedParameterJdbcTemplate，应避免依赖自动类型推断，改用 setObject() 并明确传入 SQL 类型：
// 使用 NamedParameterJdbcTemplate
Map<String, Object> params = new HashMap<>();
params.put("startDate", lookbackDays); // 仍传 DateTime
// ✅ 正确：通过 SqlParameterValue 强制指定类型
SqlParameterSource paramSource = new MapSqlParameterSource(params)
.addValue("startDate",
new SqlParameterValue(Types.TIMESTAMP_WITH_TIMEZONE, lookbackDays));或在原生 PreparedStatement 中：
PreparedStatement ps = connection.prepareStatement(sql); ps.setObject(1, lookbackDays, Types.TIMESTAMP_WITH_TIMEZONE); // 显式声明
2. 升级至 Java 8+ 时间 API（长期推荐）
Joda-Time 已进入维护模式，官方推荐迁移到 java.time（JSR-310）。LocalDateTime/OffsetDateTime/ZonedDateTime 原生受现代 JDBC 驱动支持，无需额外类型注册：
OffsetDateTime lookback = OffsetDateTime.now().minusDays(60);
// 直接传入，PostgreSQL JDBC 4.2+ 可自动识别
params.put("startDate", lookback);同时更新实体映射（需 Hibernate 5.2+ 和 hibernate-java8 模块）：
@Column(name = "created_date", nullable = false, updatable = false) @CreationTimestamp protected OffsetDateTime createdDate = OffsetDateTime.now();
3. 确保 Jadira Type 配置完整（若必须保留 Joda）
检查 persistence.xml 或 Spring Boot 配置中是否已启用 PersistentDateTime 的完整注册：
<property name="jadira.usertype.autoRegisterUserTypes" value="true"/>
并确认依赖版本兼容性（如 usertype.core:5.0.0.GA 适配 Hibernate 5.x）。
⚠️ 重要提醒：
- 不要依赖 minusXxx() 方法的“副作用”来规避类型问题；
- 避免在生产代码中使用 now() 作为默认值（易引发时区不一致）；
- 所有时间字段应统一使用带时区类型（如 OffsetDateTime 或 DateTime + 显式 UTC 存储）；
- 测试时务必覆盖跨时区、夏令时切换等边界场景。
综上，该问题本质是 JDBC 类型系统与旧式时间库集成的兼容性挑战。通过显式类型声明或向标准时间 API 迁移，即可彻底消除不确定性，提升代码健壮性与可维护性。
