Date

In short: Representing date/time values in Java — today done via the modern java.time package (LocalDate, LocalDateTime); the old java.util.Date class has been considered outdated since Java 8.

In more detail: java.util.Date had fundamental design problems (among them being mutable and a confusing month numbering starting at 0) — java.time.LocalDate/LocalDateTime are immutable and significantly less error-prone. For date calculations (e.g. “in 7 days”), java.time offers dedicated methods like plusDays(7).

In Depth

LocalDate today = LocalDate.now();
LocalDate birthday = LocalDate.of(2026, 12, 24);
LocalDate inOneWeek = today.plusDays(7); // returns a NEW object, today stays unchanged!
 
Period age = Period.between(birthday, today);
System.out.println(age.getYears() + " years");
 
LocalDateTime timestamp = LocalDateTime.now();
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("dd.MM.yyyy HH:mm");
System.out.println(timestamp.format(formatter)); // e.g. "17.09.2026 14:30"

Because LocalDate/LocalDateTime/Period are immutable, today.plusDays(7) does NOT change the today object — it returns a completely new object. A common mistake is ignoring the result (today.plusDays(7); with no assignment) and wondering why today remains unchanged. For timezone-aware timestamps, there’s additionally ZonedDateTime or Instant (for a pure UTC point in time with no timezone info, typical for server timestamps).

The three central classes at a glance

LocalDate stores only a date with no time (2026-12-24), LocalTime only a time with no date (14:30:00), LocalDateTime combines both. None of the three classes know a timezone — for timezone-aware timestamps (e.g. “24.12.2026, 14:30 Berlin time”), there’s ZonedDateTime:

ZonedDateTime berlin = ZonedDateTime.now(ZoneId.of("Europe/Berlin"));
ZonedDateTime newYork = berlin.withZoneSameInstant(ZoneId.of("America/New_York"));
System.out.println(berlin);   // e.g. 2026-09-17T14:30+02:00[Europe/Berlin]
System.out.println(newYork);  // the same instant, displayed in a different timezone

Why java.util.Date is considered outdated

The old java.util.Date class (from the first Java versions) had several fundamental design flaws: objects were mutable, which could lead to subtle bugs in concurrent code, month numbering started at 0 (January = month 0), and many methods had already been marked “deprecated” since Java 1.1, but remained usable for compatibility reasons. java.time (also known as JSR-310, introduced in Java 8) was deliberately designed as a complete redesign, heavily inspired by the popular third-party library Joda-Time.

Parsing and formatting

Date values from user input or files are usually available as text and have to be parsed — the same DateTimeFormatter can be used both for formatting and for parsing:

DateTimeFormatter f = DateTimeFormatter.ofPattern("dd.MM.yyyy");
LocalDate date = LocalDate.parse("24.12.2026", f);

A common runtime error is a DateTimeParseException when the input format doesn’t exactly match the defined pattern (e.g. input "24-12-2026" for a pattern that expects dots).

Comparison and sorting

LocalDate/LocalDateTime implement Comparable, so they can be compared and sorted directly, without writing your own comparison code:

LocalDate a = LocalDate.of(2026, 1, 1);
LocalDate b = LocalDate.of(2026, 6, 1);
 
System.out.println(a.isBefore(b)); // true
System.out.println(a.compareTo(b)); // negative value, since a comes before b
 
List<LocalDate> dates = new ArrayList<>(List.of(b, a));
Collections.sort(dates); // automatically uses compareTo()

isBefore()/isAfter()/isEqual() are often more readable than a raw compareTo() < 0, especially in conditions like if (today.isAfter(deadline)).

See also: Errors, Non-primitive Types