All 15 Java Date & Time API (java.time) questions
More in Java Date & Time API (java.time)
How would you get the current date and time, and how does specifying an explicit ZoneId (versus relying on the system default) affect the result of LocalDate.now() or LocalDateTime.now()? What is the difference between LocalDate, LocalTime, LocalDateTime, and ZonedDateTime, and when would you use each? How would you calculate the difference between two dates or times using Period and Duration, and what's the distinction between these two classes? How do you parse and format date/time values using DateTimeFormatter, and how does this replace the older, notoriously thread-unsafe SimpleDateFormat class? How would you use TemporalAdjusters to compute dates like 'the next Monday' or 'the last day of the month' relative to a given LocalDate? How would you calculate a person's age or the number of days until a recurring annual event (like a birthday) using ChronoUnit, and what's a common pitfall with leap-year birthdays (February 29)? What is the significance of storing date-time values in UTC in a database or when transmitting between systems, rather than storing them in a specific local timezone? How would you determine whether a given year is a leap year, and calculate the number of days in a specific month, using the java.time API's built-in support rather than hand-writing this classic calendrical logic? How does the Instant class represent a point in time, and how does it differ fundamentally from ZonedDateTime in terms of what it actually represents and how it should be used? How would you correctly handle daylight saving time (DST) transitions when performing date-time arithmetic with ZonedDateTime, and what specific pitfalls exist around the 'spring forward' and 'fall back' transitions?
Advertisement
Back to results for “Concurrency & Threads”
Java › Java Date & Time API (java.time)

Why was the modern java.time API (introduced in Java 8) created to replace the legacy Date and Calendar classes, and what specific problems did the old classes have?

Beginner

Answer

The legacy java.util.Date and Calendar classes suffered from serious, well-documented design flaws: Date was mutable (making it unsafe to share/cache without defensive copying), had confusing zero-based month numbering (January = 0) and offset year values (years counted from 1900), and mixed date/time/timezone concepts into one poorly-designed class; Calendar was notoriously difficult to use correctly (verbose, mutable, and inconsistent API) and neither class was thread-safe -- java.time (based on the well-regarded Joda-Time library, led by its original author) fixed all of these issues with a comprehensively redesigned, immutable, thread-safe API with clear separation between date-only, time-only, date-time, and timezone-aware concepts.
// Legacy, error-prone approach
Date oldDate = new Date(2024 - 1900, 0, 15);  // confusing offset year AND zero-based month for January 15, 2024!

// Modern, clear approach
LocalDate newDate = LocalDate.of(2024, 1, 15);  // January 15, 2024 -- reads exactly as intended, no offsets
Real-world example A team migrating a legacy codebase from java.util.Date to java.time.LocalDate discovers and fixes several subtle date-calculation bugs along the way that had been caused by Date's notoriously confusing zero-based month numbering, bugs that had gone unnoticed for years due to how easy that specific mistake is to make and how hard it is to spot in a code review.

Common follow-ups: Why is immutability specifically such a valuable property for a date/time class, beyond just general good practice?;What specific library inspired java.time's design, and did that library's author actually work on java.time itself?

Concurrency & Threads;Design Patterns in Java
All 15 Java Date & Time API (java.time) questions