How to Handle Dates in Java

Summary

Most tools/frameworks/databases give programmers poor choices for date types and offer very misleading behaviors. Even experienced programmers get confused and choose wrong types, what's worse - they take the misleading behaviors for granted. The biggest evil is unnecessary timezone conversions.

Timestamps and local dates - different paradigms

Timestamp

A timestamp is a moment on the time-line. It is always in UTC, because it doesn't need to be convenient for the end user, and because it needs to be unambiguous. In the Java world a timestamp can be represented as (ignoring milliseconds/nanoseconds precisions for simplicity):

long - the number of milliseconds passed from the Unix epoch (1970-01-01T00:00:00 in UTC). It's always in UTC by definition.
java.time.Instant - the modern (java8+) class. In simple words: it's a wrapper around the long (remember, we are ignoring nanoseconds for simplicity).
java.util.Date - the legacy (pre-java8) class. Similar to java.time.Instant from the paradigm perspective.
java.sql.Timestamp - also similar in paradigm. Based on java.util.Date (extends it) and should be considered a member of the legacy date "framework" (java.util.Date, java.util.Calendar, etc), but unfortunately it's still a thing, because it's still used in JDBC drivers (e.g. MySQL).
string like "1970-01-01T00:00:00Z" - also a very good representation that is both human-readable and unambiguous ("Z" means UTC and clearly states it's not a "local date").

Important! If you deal with a number of seconds/milliseconds/etc. then it must be in UTC, otherwise it would be too confusing. For example, java.lang.System.currentTimeMillis() in Java and date +%s command in Unix return milliseconds/seconds in UTC. Please drop me a comment if you know a tool or a framework that would deal with non-UTC numbers.

The representations above can be thought of as timezone-agnostic. You may disagree, because they do have a timezone, the UTC timezone, but UTC is a part of the definition, not a part of the data. The practical takeaway is that all of these invocations produce the same results on computers with different timezones:

System.currentTimeMillis()
new Date()
new Timestamp(System.currentTimeMillis())
Instant.now()
Instant.now().toString()

and we can convert between the types without specifying a timezone (or even without implicitly taking computer's timezone).

Local Date

A local date is a date/time from a human perspective, e.g. as seen on a wall clock. It's not good for computers, because it's impossible to convert it to an unambiguous moment on the time-line without knowing the timezone. Local dates can be represented as:

java.time.LocalDate/java.time.LocalDateTime - the modern (java8+) classes.
string like "1970-01-01 00:00:00" - note that there is no "Z" or "UTC".

So, "1970-01-01T00:00:00Z" is a timestamp, "1970-01-01T00:00:00" is a local date, very different notions.

Unfortunately, tools/frameworks often confuse timestamps and local dates

They try to be user-friendly, but it almost always turns out awful. For example, consider the ill-behaved java.sql.Timestamp.toString() method. new java.sql.Timestamp(0L).toString() returns "1970-01-01 03:00:00.0" for the Moscow timezone and here is what actually happens:

First, it takes the computer's system timezone (Moscow).
Then, all of a sudden, it switches the paradigm from timestamp to local date using the obtained system timezone.

The consequences are:

The code is not portable, it will behave differently on different computers.
The toString() contract is violated, because java.sql.Timestamp.toString() represents a different paradigm.
The system timezone is used implicitly which confuses a lot of developers that take the behavior for granted and don't even notice when a timestamp becomes a local date.

In contrast, the modern equivalent java.time.Instant.ofEpochMilli(0).toString() would return "1970-01-01T00:00:00Z" irrespective of computer's timezone. Even if we want to switch to the local date paradigm - it will force us to provide an explicit timezone, e.g. Instant.ofEpochMilli(0).atZone(zoneId).toLocalDateTime() where zoneId can be, for example, ZoneId.systemDefault() or ZoneOffset.UTC.

It's not only the legacy Java classes problem

Consider MySQL's TIMESTAMP behavior: MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval.

Avoid unnecessary timezone conversions

It's not trivial, e.g. some local times may not exist due to hour shifts, usually libraries add special handling for edge cases.
You may convert with one tool/library/database and then convert back with another, their timezone databases may differ (I have encountered it personally), so we get a bug.
Usually it makes us keep the timezone around, so we can go back and forth consistently.

Guidelines

Stick to Java8 (java.time package) dates and try to avoid the legacy (package java.util) dates. java.sql.* dates are also purely designed, try to avoid them as well. History: before Java 8 it was suggested everywhere to avoid using Java date classes (java.util dates) and to use joda-time instead. In Java 8 they added new "date framework" (package java.time) that was modelled on joda-time, some people would even say that joda-time was put to java 8.
Normally we need only timestamps, not local dates (disclaimer: I'm a server-side developer, so I may be biased). A good example where a local date is needed is for final rendering for the user, so it's a timestamp on the server, it is sent as a timestamp to the browser/app and then the browser/app makes the conversion based on user's timezone settings. The reverse is the same when the user puts a date to an input in UI - only one conversion at the very beginning, and then we work with timestamps only.

Concerns with java8 dates

This is what I don't understand or don't like personally, I'm sure there were reasons for the design choices, because java8 dates are really good.

java8 dates make a clear distinction between timestamps and local dates, and they usually force the developer to provide an explicit timezone when converting, for example, in order to convert from java.time.Instant to java.time.LocalDateTime I would have to do LocalDateTime.ofInstant(Instant.now(), ZoneOffset.UTC), but sometimes the system timezone is taken implicitly, e.g. LocalDateTime.now() (consider using java.time.LocalDateTime.now(java.time.ZoneId) instead).
There are LocalDate and LocalDateTime classes. Classes like YearMonth, Year, etc. are similar to those in nature (you can convert without timezones, e.g. Year.of(LocalDate.now().getYear()). So Year, for example, should be called LocalYear for consistency.
I encounter it very often when I need an Instant equivalent to Year, YearMonth, etc. (so I can convert back and forth without any timezones), but java8 dates don't have it. So I'm left with 2 workarounds. The first is to truncate Instant (truncatedTo method), but there is no check if the non-relevant time fields (e.g. if year then month, day, hours, etc. all should be zeros) are always zeros. The second is to convert to Year, YearMonth, etc. using UTC which is not ideal, because an effort should be made to keep it consistent everywhere.

Useful links

My popular stackoverflow answer regarding dates
Stackoverflow profile to see interesting answers from the author of Joda-Time who also worked on java8 times.