JPA，Glassfish，Mysql:UTC时间转换发生两次

我快发疯了。。。我最近注意到，当我访问

日期

字段时，我的JPA管理实体中的时间显示错误：

• 我的个人时区是CEST，运行Glassfish和MySQL的机器也是如此
• Glassfish被指示使用UTC作为默认时区：a

  @Startup

  -bean设置

  Timezone.setDefault（Timezone.getTimeZone（“UTC”）

• 在persistence.xml中禁用了缓存

下面是发生的情况：

• 实体A具有

  java.util.Date

  的字段

  syncTimestamp

• 触发特定REST资源时，时间戳设置为now:

  a.setSyncTimestamp（new Date（））

  。让我们假设我挂在墙上的时钟是14:30:00（为简洁起见省略了日期）
• 该实体是受管理的，因此更新将在数据库中结束。数据库中的行（类型为

  DATETIME

  ）显示预期值“12:30:00h”-CEST当前比UTC早2小时
• 在同一事务中访问getter会将时间戳输出为“12:30:00.123Z”（注意毫秒）
• 再次从数据库检索实体（禁用缓存）后，在单独的事务中访问getter，输出“10:30:00Z”

因此，当从DB加载实体时，看起来JPA再次从它认为的CEST时间戳转换为UTC，减去2小时

我读过很多关于JPA和时区等的帖子。我学到的是：

java.util.Date

和MySQL

DATETIME

都不了解时区。这应该不是问题，只要一切都被认为是“UTC”，对吗？现在为什么JPA（我想？）会转换这个值

（附：我发现了一篇帖子。它建议将JVM设置为UTC时区——但这不是我的启动Bean所做的吗？）

---

编辑：发现缺少一点关键信息。为了准备Glassfish集群，我将EJB计时器服务的数据库移到了MySQL数据库中。结果，JDBC驱动程序被从应用程序提取到glassfish lib目录。

好的，我已经发现了发生了什么，以及如何修复它

看起来是这样的，因为EJB计时器服务是在我的启动之前启动的，mysql JDBC驱动程序是用时区加载和初始化的（当时是系统默认值=CEST）

稍后将默认时区设置为UTC不会再影响JDBC驱动程序（这可能是glassfish的错误吗？）

解决方案是将JVM的默认时区设置为UTC：

asadmin create-jvm-options -Duser.timezone=UTC
asadmin restart-domain

---

好的，我已经知道发生了什么，以及如何修复它

看起来是这样的，因为EJB计时器服务是在我的启动之前启动的，mysql JDBC驱动程序是用时区加载和初始化的（当时是系统默认值=CEST）

稍后将默认时区设置为UTC不会再影响JDBC驱动程序（这可能是glassfish的错误吗？）

解决方案是将JVM的默认时区设置为UTC：

asadmin create-jvm-options -Duser.timezone=UTC
asadmin restart-domain