28

我认为这java.time.Instant是将日期存储到 DB 中的最佳选择：它最有可能是TIMESTAMP，而且您不依赖于时区，它只是时间的片刻。

JPA 支持LocalDate,等LocalTime，LocalDateTime但不支持 Instant。当然，您可以使用JadiraAttributeConverter之类的库，但为什么不支持开箱即用？

4

2 回答 2

16

我会再试一次。在这个问题上有一些讨论。最近的讨论似乎是：

mkarg 说：虽然这绝对正确，但技术上的答案有点复杂：使数据类型有资格包含在强制类型映射集中的最终谓词是什么？

有人可以说，谓词是“必要的”或“常用的”，但谁定义了“必要的”或“常用的”是什么？请参阅，对于某些应用程序，对 java.awt.Image 和 java.net.URL 的支持可能比对 LocalDate 或 ZonedDateTime 的支持更为重要。另一方面，其他应用程序可能充满了 LocalDate 但从不使用 Instant。那么具体在哪里进行切割呢？当查看 JRE 中发现的大量类型时，这变得特别复杂，很明显必须在某处进行删减。即使是与 JRE 捆绑在一起的 JavaFX，在 v8 中仍然不支持 Instant，那么为什么要 JPA 呢？而且看看目前拼图项目的进展，可能限定谓词可以简单地回答为“

无论如何，这不是由我决定的。我确实支持您的请求，并且希望看到对所有 Java Time API 时间的支持，特别是对于 Instant 和 Duration，并且您的请求有杰出的支持者，例如我最近了解到的 Java Champion Arun Gupa。但我怀疑最终的答案是否会像我们希望的那样简单而令人满意。

也许简单地设置另一个 JSR 会更好，比如“Java 平台的通用数据类型转换”，它提供了比日期和时间更多的映射，但也不会绑定到 JPA，但也可以被 JAXB 使用，JAX-RS，可能还有更多的 API 来处理将“转换为”的问题？拥有这样的车辆确实会大大减少样板。

TL-DR; 有很多类型。我们必须在某处划清界限。

有一个新问题要添加到未来的 JPA 版本中。

我在Douglas Surber的一个线程上发现的另一个有趣的分析（适用于 JDBC）：

JDK 8 版本的 JDBC 包括对对应于 310 个类的大多数 SQL 类型的支持。

  • 日期 - 本地日期
  • 时间 - 本地时间
  • 没有时区的时间戳 - LocalDateTime
  • 带有时区的时间戳 - OffsetDateTime

JDK 8 版本的 JDBC 不包括 INTERVAL 类型和对应的 310 类之间的映射。

没有与任何其他 310 类完全对应的 SQL 类型。因此，JDBC 规范对所有其他类都保持沉默。

我强烈鼓励 JDBC 开发人员使用新的 310 类。java.util.Date、java.sql.Date、java.sql.Time 和 java.sql.Timestamp 存在问题。您应该认为它们已弃用。310 的课程非常出色。

道格拉斯

TL：博士；我们刚刚为您在数据库中存储时态数据的 4 种可能方式中的每一种选择了一种 Java 8 类型。

最后，如果您通读这个帖子，就会发现保持标准 API 小而简单的文化压力似乎很大。

于 2018-03-15T21:11:27.860 回答
-3

这不是 JPA 问题，而是 JDBC 问题。

JDBC 支持 Date、Timestamp、LocalDate、LocalTime 和 LocalDateTime，但不支持 Instant。

这不是 Java 问题，而是 SQL 问题，其中存储在数据库中的是年-月-日-时-分-秒结构。

想想 SQL 函数：YEAR() MONTH() 等...

自 1970 年以来，这些函数不能应用于简单的毫秒编码。它们确实需要 LocalDateTime 构造来执行这些功能。

于 2018-03-18T13:26:45.980 回答