java - JPA TemporalType.Date 给出错误的日期

Question

我有一个类，它有一个日期字段，表示一条数据的“有效起始”日期。它是这样定义的:

@Temporal( TemporalType.DATE )
private Date validFrom;

在我从数据库中提取日期并显示它的那一刻，一切似乎都运行良好。如果我在前端选择日期 2003 年 9 月 18 日，然后在我 checkin 数据库时​​保存它，确定这是保存的日期(数据库是 MySQL 5.5.9 列类型是 DATE)。但是，当我拉出一个列表记录时，显示的日期是 2003 年 9 月 17 日 - 一天前。

如果我选择年初或年底的日期，例如 2003 年 3 月 26 日或 2003 年 12 月 25 日，一切都很好，所以我猜这与夏令时有关，但错误在哪里？由于数据库似乎持有正确的日期，我猜它一定是当 JPA 转换回 java.util.Date 时 - java.util.Date 是用于日期的最佳类吗？我见过一些人们使用日历的例子，但这似乎很重，我不确定它与基于 JSF 的前端的工作情况如何。

Answer 1

非常抱歉，到目前为止所有的答案通常都不正确。答案很简单，但需要我们分开五点:

1. DATE = java.sql.Date，它是 java.util.Date 的一个包装器，它是 UTC 时区中自 Epoch 以来的毫秒数。因此，这具有固定 GMT+0 (UTC) 时区中的年/月/日/时/分/秒。但请注意，java.sql.Date 将时间分量设置为零!
2. TIMESTAMP = java.sql.TimeStamp，它是一个围绕 Date 的组件包装器，它添加了小数秒以支持 SQL DATE 类型标准。这个类/类型与这个问题无关或不需要，但简而言之，它有日期加时间。
3. 数据库按定义存储 DATE 对象(使用 UTC 作为 Java 的偏移量)，但如果在数据库中配置为不同的时区，可能转换时间。默认情况下，大多数数据库默认为本地服务器时区，这是一个非常糟糕的主意。女士们，先生们……总是将 DATE 对象存储在 UTC 中。继续阅读...
4. JVM 和时区中的时间需要正确。由于 Date 对象使用 UTC，是否会为您的服务器时间计算偏移量？考虑到强烈建议将服务器时间设置为 GMT+0 (UTC)。
5. 最后，当我们想要从数据库中渲染 DATE 时(使用 JSF 或其他)，它应该设置为 GMT+0 时区，并且如果从服务器端也这样做.. . 你的日期和时间总是一致的、引用的和所有的好东西。剩下的就是渲染时间，这是用户代理(例如，对于 Web 应用程序)可以用于将 GMT+0 时间转换为用户“本地”时区的地方.

总结:在服务器、数据库、Java 对象中使用 UTC (GMT+0)。

DATE 和 TIMESTAMP 仅从数据库的角度来看不同，因为 TIMESTAMP 带有额外的秒数。两者都使用 GMT+0(隐含)。 JodaTime 是处理所有这些问题的首选日历框架，但不会解决 JVM 与数据库时区设置不匹配的问题。

如果从 JVM 到 DB 的应用程序设计不使用 GMT，由于夏令时、时钟调整以及在世界本地时钟中进行的各种其他区域游戏......事务的时间和其他一切都会永远被歪曲，非引用，不一致等。

关于数据类型的另一个很好的相关答案:java.util.Date vs java.sql.Date

还请注意，Java 8 的更新具有更好的日期/时间处理(最终)，但这并不能解决运行 JVM 的服务器时钟位于一个时区而数据库位于另一个时区的问题。在这一点上，总是有翻译发生。在我使用的每个大型(智能)客户端中，出于这个原因，数据库和 JVM 服务器时区都设置​​为 UTC，即使它们的操作主要发生在其他时区。