我认为java.time.Instant是将日期存储到数据库中的最佳选择：它最有可能是 TIMESTAMP 而且你不依赖于时区，它只是一个时刻时间。
JPA支持LocalDate，LocalTime，LocalDateTime等，但不支持即时。当然，您可以使用AttributeConverter或某些类似Jadira的库，但为什么不支持开箱即用？
答案 0 :(得分：8)
我会再试一次。 the issue中有一些讨论。最近的讨论似乎是：
mkarg说：虽然这是绝对正确的，但技术上的答案是 有点复杂：构成数据类型的最终谓词是什么 是否有资格加入强制类型映射集？可以说，谓词“必不可少”或“是常见的” 使用“，但是谁定义了什么”必要“或”常用“？请参阅 一些应用程序，支持java.awt.Image和java.net.URL可能 比支持LocalDate或ZonedDateTime要重要得多。上 另一方面，其他应用程序可能充满了LocalDate但是 从不使用Instant。那么究竟要切割的地方呢？这变成了 在查看所发现的大量类型时尤其复杂 在JRE中，很明显必须在某个地方进行切割。甚至 与JRE捆绑在一起的JavaFX不支持Instant 在第8节，为什么要JPA？并看着目前的进展 项目拼图，可能是合格的谓词可能只是 回答“特定拼图模块中的所有类型”？
无论如何，我不应该决定。我支持你的要求，并且 我很乐意看到对所有Java Time API时间的支持， 特别是对于即时和持续时间，您的要求非常突出 支持者，比如我所学习的Java Champion Arun Gupa 最近。但我怀疑最后的答案是否会令人满意 我们很乐意拥有它。
也许最好简单地设置另一个JSR，比如“Common “Java平台的数据类型转换”，提供了更多功能 映射不仅仅是日期和时间，而且也不会受到JPA的约束 但也可以由JAXB，JAX-RS以及可能更多的API使用 处理转变为“问题”的问题？有这样的车辆 真的会减少样板很多。
<强> TL-DR;有很多类型。我们不得不在某处画线。
将a new issue添加到将来的JPA版本中。
我在a thread Douglas Surber找到的另一个有趣的分析（适用于JDBC）：
JDK 8版本的JDBC包括对大多数SQL类型的支持 对应310个类。
DATE - LocalDate TIME - LocalTime 带时区的TIMESTAMP - LocalDateTime TIMESTAMP WITH TIME ZONE - 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：DR;我们为您在数据库中存储时态数据的4种可能方法中的每一种选择了一种Java 8类型。
最后，如果您通读this thread，那么标准API的存在就会面临巨大的文化压力。
答案 1 :(得分：0)
这不是JPA问题，而是JDBC问题。
JDBC支持Date，Timestamp，LocalDate，LocalTime和LocalDateTime，但 NOT Instant 。
这不是一个Java问题，而是一个SQL问题，即存储在数据库中的内容是年 - 月 - 日 - 时 - 分 - 秒构造。
考虑SQL函数： 年（） 月（） 等...
自1970年以来，这些功能不能应用于简单的毫秒数。它们确实需要LocalDateTime构造来执行这些功能。