Hibernate 使用 java.sql.Date 是否错误？

Question

I am reaching out to the community here because either I found an issue with Hibernate or I just don't understand how to use java.sql.Date and java.time.LocalDate .

我遇到了一个问题，我的数据库在 UTC 时区，而我的客户在 EST。 我在数据库中有一个名为ETA的DATE类型的字段，例如在记录上设置为2019-09-10 。 当我在 EST 中读取日期时，它变为2019-09-09 。 根据文档的DATE字段没有时区信息。

当 Hibernate 读取值时，它使用DateTypeDescriptor.java class。 However, the problem with that class is that it will first try to read the value as a java.sql.Date (in the rs.getDate( name ) part) and then call java.sql.Date.toLocalDate() in the javaTypeDescriptor.wrap()部分，它的实现很差，因为它的作用是剥离时区偏移信息，只是简单地返回一个日期。 这使得2019-09-09T20:00:00.000-0400 （在数据库中为2019-09-10 ）成为2019-09-09没有时区偏移部分。

我认为问题是 Hibernate 调用rs.getDate()的部分，因为它必须返回java.sql.Date 。 现在， MySQL 驱动程序包含一个方法public LocalDate getLocalDate(int columnIndex)来获取LocalDate ，所以我不明白为什么 Hibernate 不使用该方法。

我发现有人已经向他们提出了同样的问题，但他们似乎并不认为这是一个问题。

因此，我在这里了解 - Hibernate 是否存在错误，或者我只是不理解如何在DATE (DB) 和LocalDate (Java) 类型之间进行转换。

PS：我使用最新的 Hibernate 5.4.5 和最新的 JPA 2.2。

Answer 1

尝试 Hibernate 5 和配置选项hibernate.jdbc.time_zone 。 这是强制它使用 JDBC API 的官方方式，这些 API 在UTC时区使用Calendar实例。

也就是说，我发现这方面存在很多问题。 JDBC 驱动程序和使用数据库的人经常会犯这种微妙的错误。 这就是为什么我们最终放弃并将毫秒（以 UTC 为单位）放入数据库的原因。 因此，对于所有三种时间类型，列类型始终为NUMBER(16) 。

这允许我们编写返回可预测结果的特殊转换器，独立于 JDBC 驱动程序、数据库/VM/OS 时区。

然后，程序员可以专注于尝试理解为什么时区不能按照他们认为应该的方式工作:-)