What's the difference between TimeZone and ZoneId?

Question

What is the difference between the java.util.TimeZone and java.time.ZoneId classes in JDK?

Is there more information about the differences between the two to help me decide which class I should use in my project?

Answer 1

All the "old" time-related types (java.util.Calendar, java.util.Date, java.util.TimeZone etc) are still present and may well never be deprecated because so much code depends on them. If those types were deprecated as a whole (rather than just the particularly bad parts of them, such as the Date(int, int, int) constructor) I suspect it would cause so many deprecation warnings (and the work in migration would be so large) that almost all companies would just turn off or ignore warnings, instead of migrating to java.time.

However, for any new code (or at the very least whole new projects) it's a much better idea to use java.time and related packages for everything to do with handling time - including using ZoneId instead of TimeZone.

Answer 2

Use ZoneId, avoid TimeZone

You said:

What is the difference between the java.util.TimeZone and java.time.ZoneId classes in JDK?

Modern	Legacy
java.time.ZoneId	java.util.TimeZone

The java.util.TimeZone class is part of the terribly-flawed legacy date-time classes. Avoid the legacy classes. Use only java.time classes, use only java.time.ZoneId or its subclass java.time.ZoneOffset.

The legacy class java.util.TimeZone has one feature not available in its replacement: The ability to change the JVM’s current default time zone. See TimeZone.setDefault.

Generally, changing the JVM’s current default time zone is a risky move as it immediately affects all code in all threads of all apps running within that JVM. And, for the most part, you can and should write your code to explicitly use a particular time zone that you desire/expect. Depending on the JVM’s current default time zone is a gamble.

You said:

From what I have researched, TimeZone is the old time zone class, and ZoneId is the new time zone class.

Yes, ZoneId replaces TimeZone

Will ZoneId replace TimeZone in the future?

Already has, as of the unanimous adoption of JSR 310 in 2014.

• Use java.time.ZoneId
• Avoid java.util.TimeZone

The only exception is setting the JVM’s current default time zone. But, as discussed above, that is usually unnecessary and likely a poor solution.

tzdata

By the way, know that politicians around the world have shown a proclivity for messing with the rules of their respective time zones. The rules change surprisingly often, sometimes with little to no warning.

If any time zone of concern to your stakeholders is changing, you must:

• Replace the tzdata within your JVM. Both ZoneId & TimeZone obtain their time zone rules data from that file.
• Replace the tzdata in your host OS for use by non-Java apps.
• Replace the tzdata contained in your database engine such as with PostgreSQL.

Deprecation

If yes, why is TimeZone not marked as @Deprecated?

The legacy classes were marked deprecated in the OpenJDK codebase at one point, reportedly. Then mysteriously unmarked.

I imagine the reason is the likely freak-out as explained in Answer by Jon Skeet.

Logically, the legacy date-time classes should be officially deprecated. All the more so given that Deprecation in Java has been refined with a distinction between merely deprecated versus deprecated for eventual removal.

But that deprecation is unlikely. Nevertheless you should consider the legacy date-time classes to be effectively deprecated.

Zone vs Offset

An offset-from-UTC is merely a number of hours-minutes-seconds ahead or behind the temporal meridian of UTC.

A time zone is much more. A time zone is a named history of the past, present, and future changes to the offset used by the people in a particular region, as determined by their politicians.

Time Zone	Offset
java.time.ZoneId	java.time.ZoneOffset