我确实读过timestamps-and-time-zones-in-postgresql，并且了解到timestampTZ是作为UTC时间戳存储的，任何时区/偏移都被转换掉并丢失了。
因此，当加载带有OffsetDateTime字段的JPA /休眠实体时，绑定到此类timestampTZ字段时，偏移量来自何处？ 是否总是将其转换为JDBC连接的时区？
这是一种信息截断，实际上我们丢失了原始的时区信息，因此我们将其设置回绑定到JDBC连接的任何时区，因此，如果需要，还需要存储时区信息。我们需要那个吗？
如果以上所有条件均成立，那么使用Instant而不是OffsetBigTime来更清晰/精确吗，OffsetBigTime代表的是UTC时间点，就像timestampTZ所做的一样？ 然后，我至少必须在代码中显式地应用“正确的时区”，而不必通过某些数据库连接“神奇地”应用它。
在加载带有OffsetDateTime字段的JPA /休眠实体时，绑定到此类timestampTZ字段时，Offset来自何处
虽然我不使用JPA或Hibernate（我使用直接JDBC），但我希望您收到一个OffsetDateTime，其中偏移量是UTC之前/之后的零小时-分钟-秒。我们可以简称为“在UTC”。
您可以自己看到。检索OffsetDateTime对象，然后调用toString。如果结果文本的末尾显示+00:00或Z，则hat表示偏移量为零。
如果需要，还需要存储时区信息吗？
是的，如果您关心提交给数据库的时区或偏移量，则必须通过自己的额外编程将信息自己保存在第二列中。默认情况下，Postgres使用提交的区域或偏移量信息调整为UTC，然后丢弃该区域或偏移量信息。
我希望大多数商务应用都不会在意原始区域或偏移量。请记住，时刻（时间轴上的点）没有改变。仅挂钟时间显示不同。 Postgres就像冰岛的一个人（UTC是他们全年的永久时区），接到东京或蒙特利尔某个人的电话。如果两个人都抬头看着墙上的时钟，那么东京的人会比冰岛的Postgres人早几个小时。蒙特利尔人看到一天的时间挂在继承人自己的墙上，要比冰岛的Postgres人晚几个小时。
检索偏移量为零的OffsetDateTime对象时，可以轻松调整到所需的任何时区。
OffsetDateTime odt = myResultSet.getObject( …,OffsetDateTime.class ) ;
ZoneId z = ZoneId.of( "Asia/Tokyo" ) ;
ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;
使用Instant会更清晰/准确吗
是的！
出于任何原因，控制JDBC API的人们在JDBC 4.2中做出了奇怪的选择，要求支持OffsetDateTime，而不需要支持Instant或ZonedDateTime。我想象中的大多数其他应用中，这两个类经常被很多使用。因此，他们选择的逻辑使我逃脱了。
您的JDBC驱动程序可能支持Instant 或ZonedDateTime。只是尝试看看。 JDBC 4.2 API并不禁止这种支持。 API没有提及这些类型。因此，对Instant或ZonedDateTime的支持是可选的。
然后，我至少必须在代码中显式地应用“正确的时区”，而不必通过某些数据库连接“神奇地”应用它……
如果通过兼容JDBC 4.2的驱动程序检索 java.time 对象，看到它们将区域或偏移量应用于检索到的值，我会感到非常惊讶。我希望您只会收到偏移量为零的OffsetDateTime对象。但是我不记得他的行为是规范中规定的一种或另一种方式。因此，请始终测试您特定的JDBC驱动程序的行为。
请注意，以文本形式获取值或使用其他中间件工具（例如PgAdmin）可能会注入一些默认区域或偏移量。尽管出于很好的意图，但我认为这是一种反功能，会造成一种幻觉，即某个特定区域实际上并未保存在数据库中。
使用哪个时区从Postgres timestampTZ解组OffsetDateTime？
首先，要知道偏移量仅在本初子午线之前或之后的小时，分钟和秒数。时区更多。时区是过去，现在和将来更改特定区域的人们使用的偏移量的历史。
因此，标题的用语是矛盾的。 OffsetDateTime不涉及任何时区，也就是名称。对于时区，请使用ZonedDateTime类。
