Java 什么偏移量用于从Postgres timestampTZ解组OffsetDateTime？

我确实读过并理解，timestampTZ存储为UTC时间戳，任何时区/偏移量都会被转换掉并丢失

那么，当加载带有OffsetDateTime字段的JPA/Hibernate实体时，该字段绑定到这样一个timestampTZ字段，那么偏移量从何而来？ 它总是转换成JDBC连接的时区吗

这是一种信息截断，我们实际上丢失了原始的时区信息，因此我们被设置回JDBC连接绑定到的任何时区，因此，如果需要，我们需要额外存储时区信息

如果上述所有条件都成立，那么使用Instant而不是OffsetBigTime（它代表UTC时间点，与timestampTZ完全相同）不是更清晰/精确吗？ 然后我必须至少在代码中显式地应用“适当的时区”，而不是通过某个DB连接“神奇地”应用它

当加载带有OffsetDateTime字段（绑定到这样的timestampTZ字段）的JPA/Hibernate实体时，偏移量从何而来

虽然我不使用JPA或Hibernate（我使用的是纯JDBC），但我希望您会收到一个

OffsetDateTime

，其中偏移量为UTC前/后零小时分秒。我们可以将其简称为“UTC”

你可以自己看。检索

OffsetDateTime

对象，并调用

toString

。如果结果文本末尾显示

+00:00

或

Z

，则表示偏移量为零

如果需要，我们需要额外存储时区信息

是的，如果您关心提交到数据库的时区或偏移量，则必须使用自己的额外编程将该信息保存在第二列中。默认情况下，Postgres使用提交的区域或偏移信息调整为UTC，然后放弃该区域或偏移信息

我预计大多数商业应用程序并不关心原始区域或偏移量是什么。请记住，时刻，时间线上的点，是不变的。只有挂钟的时间不同。博士后就像冰岛人（UTC是他们全年的固定时区）接到东京或蒙特勒尔某人的电话。如果两人都抬头看墙上的时钟，东京人看到的时间比冰岛博士后早几个小时。蒙特勒尔人认为挂在自己墙上的时钟上的时间比冰岛的博士后的时间晚了几个小时

当您检索偏移量为零的

OffsetDateTime

对象时，您可以轻松地调整到所需的任何时区

OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ;
ZoneId z = ZoneId.of( "Asia/Tokyo" ) ;
ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;

使用Instant不是更清晰/精确吗

是的

无论出于何种原因，控制JDBCAPI的人在JDBC4.2中做出了奇怪的选择，要求支持

OffsetDateTime

，但不要求支持

Instant

或

zoneDateTime

。我想，在大多数应用程序中，这两个类的使用频率要高得多。所以他们选择的逻辑我不明白

您的JDBC驱动程序可能支持

Instant

或

ZonedDateTime

。试试看。JDBC4.2API并不禁止这种支持；API没有提到这些类型。因此，支持

即时

或

分区DateTime

是可选的

然后我必须至少在代码中显式地应用“适当的时区”，而不是通过某个db连接“神奇地”应用它

如果您是通过JDBC4.2兼容的驱动程序检索java.time对象，我会非常惊讶地看到它们对检索到的值应用区域或偏移量。我希望您只会收到偏移量为零的

OffsetDateTime

对象。但我不记得他的行为在规范中以这样或那样的方式被强制执行。因此，请始终测试特定JDBC驱动程序的行为

请注意，以文本形式检索值或使用其他中间件工具（如PgAdmin）很可能会注入一些默认区域或偏移量。虽然是善意的，但我认为这是一个反特性，它造成了一个特定区域的幻觉，当它不是事实时，它被保存在数据库中。 哪个时区用于从Postgres timestampTZ中解组OffsetDateTime

首先，知道偏移量只是本初子午线前后的小时、分钟和秒数。时区更重要。时区是特定地区人民使用的偏移量的过去、现在和未来变化的历史

所以你的标题的措辞是矛盾的。

OffsetDateTime

不涉及时区，因此名称为。对于时区，请使用

ZonedDateTime

类

---

看来你是对的；本质上，Java8时间API是重复的功能，因此在Java代码中处理它会更清晰（假定Java应用程序“拥有”整个模式）。