What's the difference between ZonedDateTime and OffsetDateTime?

Question

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.

Quinn

Basically a ZonedDateTime also contains information about timezones, including DST switching etc from what I read. – Doctrinal

Answer 1

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.

Lewislewisite

Answer 2

The accepted answer give very completed explanation, perhaps below code example can provide you short and clear picture:

Instant instant = Instant.now();
Clock clock = Clock.fixed(instant, ZoneId.of("America/New_York"));
OffsetDateTime offsetDateTime = OffsetDateTime.now(clock);
ZonedDateTime zonedDateTime = ZonedDateTime.now(clock);

System.out.println(offsetDateTime); // 2019-01-03T19:10:16.806-05:00
System.out.println(zonedDateTime);  // 2019-01-03T19:10:16.806-05:00[America/New_York]
System.out.println();

OffsetDateTime offsetPlusSixMonths = offsetDateTime.plusMonths(6);
ZonedDateTime zonedDateTimePlusSixMonths = zonedDateTime.plusMonths(6);

System.out.println(offsetPlusSixMonths); // 2019-07-03T19:10:16.806-05:00
System.out.println(zonedDateTimePlusSixMonths); // 2019-07-03T19:10:16.806-04:00[America/New_York]
System.out.println(zonedDateTimePlusSixMonths.toEpochSecond() - offsetPlusSixMonths.toEpochSecond()); // -3600

System.out.println();
System.out.println(zonedDateTimePlusSixMonths.toLocalDateTime()); // 2019-07-03T19:10:16.806
System.out.println(offsetPlusSixMonths.toLocalDateTime()); // 2019-07-03T19:10:16.806

In short, use ZonedDateTime only if you want to factor in Daylight saving, typically there will be one hour difference, as you can see the example above, the offset of ZonedDateTime change from -5:00 to -04:00, in most case, your business logic might end up with bug.

(code copy from https://www.youtube.com/watch?v=nEQhx9hGutQ)

Nationalist

I'd go the opposite way: the correct one to use is usually either Instant or ZonedDateTime. IMO OffsetDateTime only exist because many existing systems (wrongly) treated "time offset" to be sufficient information about timezones (i.e. they communicate/store/handle just an offset when they should be communicating a time zone name). – Radiocarbon

@JoachimSauer When we format message for users or read their input we use ZonedDateTime & ZoneId. When we store a time event to DB we convert to UTC, OffsetDateTime is basically an instant in time. UTC dates are easy comparable (avoiding TZ info lookups). – Hettie

Most precise answer I have ever seen – Sidonius

Answer 3

Apart from programming, I am giving you an example to understand ZonedDateTime and OffsetDateTime in the real world. ZonedDateTime: let's say I am in Pakistan now and right now the data and time is 2024-03-07T13:05:00.00000 (13:05 == 01:05 pm), if I add +03:00 the time would be the current time in Thailand (15:05 == 03:05 pm), OffsetDateTime: OffsetDateTime: start by UTC+00:00 and the current time is 2024-03-07T08:05:00.00000 (08:05 am), if I add +03:00 the time would be current time in Saudi Arabia (11:05 am).

So OffsetDateTime starts from UTC+00:00 and ZonedDateTime starts from your current zone time. please refer attached wiki link

Depart