Why is java.util.Date discouraged in modern Java code, and what do you use instead?
answer
- Date = mutable long of millis since 1970 UTC
- Mutable + not thread-safe
- getYear minus 1900, getMonth 0-based
- Deprecated field accessors since 1.1
- Use java.time: Instant / LocalDate / ZonedDateTime
basics
~10 sjava.util.Date is mutable, not thread-safe, mixes a date and a time together, and has confusing deprecated methods. Use the java.time package (LocalDate, LocalDateTime, Instant) instead, which is clearer and immutable.
solid answer
~50 sjava.util.Date has several design flaws. It is mutable, so any code holding a reference can change it, which makes it unsafe to share across threads or use as a map key. Despite the name, a Date is really a single instant in time (milliseconds since the 1970 epoch, UTC) yet its API pretends to expose calendar fields like year and month through methods that are now deprecated and use odd conventions (year offset from 1900, months 0-based). It also has no concept of time zone in a useful way. Since Java 8 you should use java.time: LocalDate for a date with no time, LocalTime for a time of day, LocalDateTime for both without a zone, ZonedDateTime when a zone matters, and Instant for a machine timestamp. These types are immutable, thread-safe, and have a clear, fluent API.
go deeper
Knows Date is old and you should prefer java.time; can name LocalDate/LocalDateTime as replacements.
Explains the concrete flaws (mutable, not thread-safe, conflates date+time, deprecated accessors) and picks the right java.time type per use case.
Articulates why mutability causes aliasing and map-key bugs, that Date is really a UTC instant, and the SimpleDateFormat thread-safety trap; uses Instant vs Local* correctly.
Frames migration strategy across a codebase, boundary conversions to legacy APIs/JDBC, and sets team conventions (immutability, DateTimeFormatter constants, banning java.util.Date in new code).
## What java.util.Date actually is `java.util.Date` was part of Java 1.0 (1996). Despite the name, an instance does **not** store a calendar date like "June 20, 2026." Internally it stores a single `long`: the number of **milliseconds since the Unix epoch**, which is `1970-01-01T00:00:00Z` (Z = UTC, Coordinated Universal Time, the global reference time zone). So a `Date` is really a **point on the timeline** (an *instant*), not a human-readable date. ## Why it is discouraged **1. It is mutable.** A mutable object is one whose internal state can change after creation. `Date` has setter-style methods (e.g. `setTime(long)`, the deprecated `setYear(int)`). Mutability causes two practical problems: - *Aliasing bugs*: if you return a `Date` field from a getter, the caller can mutate your object's internal state behind your back. Defensive copying (`new Date(original.getTime())`) is the usual workaround, but it is easy to forget. - *Bad map keys*: an object used as a `HashMap`/`HashSet` key should not change while it's in the map, or lookups break. A mutable `Date` violates this. **2. It is not thread-safe.** Thread safety means multiple threads can use an object concurrently without corrupting it. Because `Date` is mutable with no synchronization, two threads writing to the same `Date` can produce a corrupted value. (The classic related trap is `SimpleDateFormat`, the legacy formatter, which is also mutable and not thread-safe — sharing one across threads silently produces wrong results.) **3. It conflates date and time and lacks a real time zone.** A `Date` is an instant in UTC, but its deprecated accessors (`getYear()`, `getMonth()`, `getHours()`, …) interpret that instant using the JVM's *default* time zone, which is implicit and surprising. There is no clean type for "just a date" or "just a time." **4. Confusing, deprecated accessors with bad conventions.** Most field methods were deprecated in Java 1.1 in favor of `Calendar`. They also use error-prone conventions: `getYear()` returns the year **minus 1900** (so 2026 is `126`), and `getMonth()` is **0-based** (January is 0, December is 11). These off-by-one conventions are a perennial source of bugs. ## What to use instead: java.time (JSR-310, Java 8+) The `java.time` package (often called the "new" date/time API, designed by the author of Joda-Time) fixes all of this. Every type is **immutable** and **thread-safe**, and each models exactly one concept: - **`LocalDate`** — a date with no time and no zone (e.g. a birthday): `2026-06-20`. - **`LocalTime`** — a time of day with no date: `14:30`. - **`LocalDateTime`** — a date + time, still no zone. - **`ZonedDateTime`** — a date + time **in a specific time zone** (handles daylight saving). - **`Instant`** — a machine timestamp (nanoseconds from the epoch, UTC) — the modern replacement for what `Date` really was. - Plus `Duration` (an amount of time, e.g. 90 minutes), `Period` (an amount of date, e.g. 2 months), and `DateTimeFormatter` (immutable and thread-safe, unlike `SimpleDateFormat`). Months in `java.time` are **1-based** (or use the `Month` enum), years are the real year, and the API is fluent: `LocalDate.now().plusDays(7)` returns a new object, leaving the original unchanged. ## Summary mental model Think of `Date` as a poorly-named, mutable wrapper around a UTC millisecond count. Prefer `Instant` when you need that timestamp, and the `Local*`/`Zoned*` types when you need human calendar concepts.
- If a Date is just milliseconds since the epoch, how do you convert it to and from the modern API?Use date.toInstant() to get an Instant, and Date.from(instant) to go back. From an Instant you can attach a zone with instant.atZone(ZoneId.of("...")) to get a ZonedDateTime.
- What is the modern, thread-safe replacement for SimpleDateFormat?java.time.format.DateTimeFormatter, which is immutable and thread-safe, so a single instance can be shared as a static constant.
saying these in an interview costs you the question
- Claiming Date stores year/month/day fields directly (it stores one long of millis)
- Saying Date is immutable
- Thinking Date carries a time zone
- Believing SimpleDateFormat is safe to share across threads