Java的ZonedDateTime持久化到timestamptz后时区信息是否丢失？如何恢复？

场景说明 #

我使用java.time.ZonedDateTime创建了带时区信息的时间戳：

2022-11-27T22:32:27.697077+09:00[Asia/Tokyo]

当JPA实体插入数据库时，由于数据库配置为UTC时区，该时间会转换为UTC时间存储，数据库中的值为：

2022-11-27 13:32:27.697077+00

相关代码与配置如下：

Java实体代码 #

@Column(name = "zoned_date_time")
private ZonedDateTime zonedDateTime;

Liquibase配置 #

<databaseChangeLog>
    <changeSet author="me" id="1669077010756-1">
       <addColumn tableName="item">
         <column name="zoned_date_time" type="timestamptz"/>
       </addColumn>
    </changeSet>
</databaseChangeLog>

验证信息 #

• 数据库插入前JVM输出：

java.time.ZonedDateTime: 2022-11-27T22:32:27.697077+09:00[Asia/Tokyo]

• PostgreSQL容器内查询结果：

select zoned_date_time from item;
->
2022-11-27 13:32:27.697077+00

• 数据库时区配置：

postgres=# show timezone;
 TimeZone
----------
 Etc/UTC

疑问解答 #

1. 数据存储到数据库后，[Asia/Tokyo]的时区信息是否会丢失？ #

会丢失。PostgreSQL的timestamptz类型本质上只存储UTC时间戳，不会保留原始的时区标识（如Asia/Tokyo）。插入时JPA会将ZonedDateTime转换为对应的UTC时间存入数据库，仅记录时间点的绝对UTC值，原始时区的ID信息不会被存储。

2. 如何还原出原时区[Asia/Tokyo]？ #

如果没有额外存储时区信息，无法准确还原。原因有两点：

• 多个时区可能对应相同的偏移量（比如某些地区和Asia/Tokyo一样使用+09:00偏移，但时区ID不同）；
• 时区偏移可能因夏令时等规则发生变化，仅靠UTC时间和偏移量无法反向推导原始时区ID。
  只有提前单独存储了Asia/Tokyo这类时区标识，才能在读取时将UTC时间转换回原时区。

3. 是否需要手动单独存储该时区信息？ #

取决于业务需求：

• 如果需要保留原始的时区上下文（比如记录用户操作时的时区，后续要按该时区展示时间），则必须单独存储时区ID（可新增一个varchar类型字段存储Asia/Tokyo这类值）；
• 如果仅需要记录绝对时间点，不需要还原原始时区，那么无需单独存储——timestamptz已经能准确表示时间点，后续可以根据需求转换到任意时区展示。

内容的提问来源于stack exchange，提问作者bobbyrne01