ZonedDateTime 和 OffsetDateTime 之间有什么区别? [英] What's the difference between ZonedDateTime and OffsetDateTime?

问题描述

我已经阅读了文档，但我仍然不知道何时应该使用其中一个:

• OffsetDateTime
• ZonedDateTime

根据文档 OffsetDateTime 应该在将日期写入数据库时​​使用，但我不明白为什么.

解决方案

问:java 8 ZonedDateTime 和 OffsetDateTime 有什么区别?

javadocs 是这样说的:

<块引用>

"OffsetDateTime、ZonedDateTime 和 Instant 都在时间线上以纳秒精度存储一个瞬间.Instant 是最简单的，简单地表示瞬间.OffsetDateTime 将与 UTC/Greenwich 的偏移量添加到瞬间，这样就可以获取本地日期时间.ZonedDateTime 添加完整的时区规则."

来源:https://docs.oracle.com/javase/8/docs/api/java/time/OffsetDateTime.html

因此，OffsetDateTime 和 ZonedDateTime 之间的区别在于后者包括涵盖夏令时调整和其他各种异常的规则.

简单地说:

<块引用>

时区 = ( UTC 偏移量 + 异常规则 )

<小时><块引用>

问:根据文档OffsetDateTime 应该在将日期写入数据库时​​使用，但我不明白为什么.

具有本地时间偏移的日期总是代表相同的时刻，因此具有稳定的排序.相比之下，具有完整时区信息的日期的含义在面对相应时区规则的调整时是不稳定的.(这些确实会发生；例如，对于未来的日期时间值.)因此，如果您存储并检索 ZonedDateTime，则实现会出现问题:

• 它可以存储计算出的偏移量……然后检索到的对象的偏移量可能与区域 ID 的当前规则不一致.

• 它可以丢弃计算出的偏移量......然后检索到的对象代表绝对/通用时间轴中与存储的点不同的点.

如果您使用 Java 对象序列化，则 Java 9 实现采用第一种方法.这可以说是处理此问题的更正确"的方法，但这似乎没有记录.(JDBC 驱动程序和 ORM 绑定大概也在做出类似的决定，并且希望能做出正确的决定.)

但是，如果您正在编写一个手动存储日期/时间值的应用程序，或者依赖于 java.sql.DateTime，那么处理 zone-id 的复杂性是......可能要避免的东西.因此，建议.

请注意，日期的含义/顺序随着时间的推移而不稳定可能对于应用程序来说是有问题的.而且由于区域规则的变化是边缘情况，问题很可能会在意想不到的时候出现.

<小时>

建议的第二个(可能的)原因是 ZonedDateTime 的构造在某些点上是不明确的.例如，在您将时钟拨回"的时间段内，结合本地时间和区域 ID 可以为您提供两个不同的偏移量.ZonedDateTime 将始终选择一个而不是另一个......但这并不总是正确的选择.

现在，对于以这种方式构造 ZonedDateTime 值的任何应用程序来说，这可能是一个问题.但是从构建企业应用程序的人的角度来看，当(可能不正确)ZonedDateTime 值是持久的并在以后使用时，这是一个更大的问题.

I've read the documentation, but I still can't get when I should use one or the other:

• OffsetDateTime
• ZonedDateTime

According to documentation OffsetDateTime should be used when writing date to database, but I don't get why.

解决方案

Q: What's the difference between java 8 ZonedDateTime and OffsetDateTime?

The javadocs say this:

"OffsetDateTime, ZonedDateTime and Instant all store an instant on the time-line to nanosecond precision. Instant is the simplest, simply representing the instant. OffsetDateTime adds to the instant the offset from UTC/Greenwich, which allows the local date-time to be obtained. ZonedDateTime adds full time-zone rules."

Source: https://docs.oracle.com/javase/8/docs/api/java/time/OffsetDateTime.html

Thus the difference between OffsetDateTime and ZonedDateTime is that the latter includes the rules that cover daylight saving time adjustments and various other anomalies.

Stated simply:

Time Zone = ( Offset-From-UTC + Rules-For-Anomalies )

---

Q: According to documentation OffsetDateTime should be used when writing date to database, but I don't get why.

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 ZonedDateTime the implementation has a problem:

• 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.

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.)

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.

Note that dates whose meaning / ordering is unstable over time may be problematic 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 ZonedDateTime is 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 ZonedDateTime will consistently pick one over the other ... but this isn't always the correct choice.

Now, this could be a problem for any applications that construct ZonedDateTime values that way. But from the perspective of someone building an enterprise application is a bigger problem when the (possibly incorrect) ZonedDateTime values are persistent and used later.

这篇关于ZonedDateTime 和 OffsetDateTime 之间有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！