Java ZonedDateTime 和 OffsetDateTime 之间有什么区别？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/30234594/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What's the difference between ZonedDateTime and OffsetDateTime?
提问by Zhenya
I've read the documentation, but I still can't get when I should use one or the other:
我已经阅读了文档，但我仍然不知道何时应该使用其中一个：
According to documentation OffsetDateTimeshould be used when writing date to database, but I don't get why.
根据文档OffsetDateTime应该在将日期写入数据库时使用，但我不明白为什么。
采纳答案by Stephen C
Q: What's the difference between java 8 ZonedDateTime and OffsetDateTime?
问：java 8 ZonedDateTime 和 OffsetDateTime 有什么区别？
The javadocs say this:
javadocs 是这样说的：
"
OffsetDateTime,ZonedDateTimeandInstantall store an instant on the time-line to nanosecond precision.Instantis the simplest, simply representing the instant.OffsetDateTimeadds to the instant the offset from UTC/Greenwich, which allows the local date-time to be obtained.ZonedDateTimeadds full time-zone rules."
"
OffsetDateTime，ZonedDateTime并且Instant都将时间线上的瞬间存储到纳秒精度。Instant是最简单的，简单地表示瞬间。OffsetDateTime将与 UTC/格林威治的偏移量添加到瞬间，这允许获得本地日期时间。ZonedDateTime添加全时间-区域规则。”
Source: https://docs.oracle.com/javase/8/docs/api/java/time/OffsetDateTime.html
来源：https: //docs.oracle.com/javase/8/docs/api/java/time/OffsetDateTime.html
Thus the difference between OffsetDateTimeand ZonedDateTimeis that the latter includes the rules that cover daylight saving time adjustments and various other anomalies.
因此，OffsetDateTime和之间的区别在于ZonedDateTime后者包括涵盖夏令时调整和各种其他异常的规则。
Stated simply:
简单地说：
Time Zone= ( Offset-From-UTC+ Rules-For-Anomalies )
Q: According to documentation
OffsetDateTimeshould be used when writing date to database, but I don't get why.
问：根据文档
OffsetDateTime应该在将日期写入数据库时使用，但我不明白为什么。
Dates with local time offsets always represent the same instants in time, and therefore have a stable ordering. By contrast, the meaning of dates with full timezone information is unstable in the face of adjustments to the rules for the respective timezones. (And these do happen; e.g. for date-time values in the future.) So if you store and then retrieve a ZonedDateTimethe implementation has a problem:
具有本地时间偏移的日期始终表示相同的时刻，因此具有稳定的排序。相比之下，具有完整时区信息的日期的含义在面对相应时区规则的调整时是不稳定的。（这些确实会发生；例如，对于未来的日期时间值。）因此，如果您存储然后检索一个，ZonedDateTime则实现会出现问题：
It can store the computed offset ... and the retrieved object may then have an offset that is inconsistent with the current rules for the zone-id.
It can discard the computed offset ... and the retrieved object then represents a different point in the absolute / universal timeline than the one that was stored.
它可以存储计算出的偏移量……然后检索到的对象可能具有与区域 ID 的当前规则不一致的偏移量。
它可以丢弃计算出的偏移量……然后检索到的对象代表绝对/通用时间线中与存储的点不同的点。
If you use Java object serialization, the Java 9 implementation takes the first approach. This is arguably the "more correct" way to handle this, but this doesn't appear to be documented. (JDBC drivers and ORM bindings are presumably making similar decisions, and are hopefully getting it right.)
如果您使用 Java 对象序列化，则 Java 9 实现采用第一种方法。这可以说是处理此问题的“更正确”的方法，但这似乎没有记录。（JDBC 驱动程序和 ORM 绑定可能正在做出类似的决定，并希望能做到正确。）
But if you are writing an application that manually stores date/time values, or that rely on java.sql.DateTime, then dealing with the complications of a zone-id is ... probably something to be avoided. Hence the advice.
但是，如果您正在编写一个手动存储日期/时间值或依赖于 的应用程序java.sql.DateTime，那么处理 zone-id 的复杂性是......可能需要避免的事情。因此，建议。
Note that dates whose meaning / ordering is unstable over time may beproblematic for an application. And since changes to zone rules are an edge case, the problems are liable to emerge at unexpected times.
请注意，随着时间的推移含义/顺序不稳定的日期可能对应用程序有问题。而且由于区域规则的变化是边缘情况，问题很可能会在意想不到的时候出现。
A (possible) second reason for the advice is that the construction of a ZonedDateTimeis ambiguous at the certain points. For example in the period in time when you are "putting the clocks back", combining a local time and a zone-id can give you two different offsets. The ZonedDateTimewill consistently pick one over the other ... but this isn't always the correct choice.
建议的（可能的）第二个原因是 a 的构造ZonedDateTime在某些点上是不明确的。例如，在您“将时钟倒回”的时间段内，结合本地时间和区域 ID 可以为您提供两个不同的偏移量。该ZonedDateTime会一贯挑一个比其他...但是这并不总是正确的选择。
Now, this could be a problem for any applications that construct ZonedDateTimevalues that way. But from the perspective of someone building an enterprise application is a bigger problem when the (possibly incorrect) ZonedDateTimevalues are persistent and used later.
现在，对于以ZonedDateTime这种方式构造值的任何应用程序来说，这可能是一个问题。但是从构建企业应用程序的人的角度来看，当（可能不正确的）ZonedDateTime值持久存在并在以后使用时，这是一个更大的问题。
