Date/Time API (JSR-310) practice questions

Worked examples for Date/Time API (JSR-310)

1. Question 1

   What is the result of compiling the following program? ```java import java.time.LocalDate; public class Main { public static void main(String[] args) { LocalDate d = new LocalDate(); System.out.println(d); } } ```

   1. A. Today's date

      This assumes a public no-arg constructor that defaults to the current date; LocalDate has no such constructor, and today's date comes from LocalDate.now().

   2. B. 1970-01-01

      This imagines a constructor defaulting to the epoch; there is no public constructor to invoke, so the code never runs.

   3. C. An exception is thrown at runtime

      The failure happens at compile time because the constructor does not exist, so no runtime exception is reached.

   4. D. Compilation failsCorrect answer

      The java.time classes expose no public constructors, so `new LocalDate()` cannot resolve and the program fails to compile; instances come only from static factories like now() and of().

   Explanation

   The java.time classes have NO public constructors — they are created exclusively through static factory methods: LocalDate.now() for today, LocalDate.of(y, m, d) for a specific date. `new LocalDate()` is a compile error.

2. Question 2

   What is the output of the following program? ```java import java.time.LocalDateTime; public class Main { public static void main(String[] args) { LocalDateTime dt = LocalDateTime.of(2025, 4, 1, 10, 30).plusHours(20); System.out.println(dt); } } ```

   1. A. 2025-04-01T30:30

      This assumes hours accumulate past 24 without advancing the date; instead the extra hours roll into the next day, and 30:30 is not a valid clock time.

   2. B. 2025-04-02T06:30:00

      The instant is right, but LocalDateTime.toString omits the seconds field when it is zero, so no trailing :00 appears.

   3. C. 2025-04-02T06:30Correct answer

      10:30 + 20 hours advances into the next day at 06:30, and toString drops the zero seconds, giving 2025-04-02T06:30.

   4. D. An exception is thrown at runtime

      Adding hours to a LocalDateTime is valid arithmetic that rolls the date as needed; nothing throws.

   Explanation

   10:30 + 20 hours rolls into the next day at 06:30 — the date component advances automatically. The toString of a LocalDateTime omits seconds when they are zero, so there is no trailing :00 (`2025-04-02T06:30:00`).

3. Question 3

   What is the output of the following program? ```java import java.time.LocalTime; public class Main { public static void main(String[] args) { LocalTime t = LocalTime.of(9, 5).plusMinutes(60); System.out.println(t); } } ```

   1. A. 09:65

      Minutes carry into hours automatically; LocalTime never holds a 65-minute value.

   2. B. 10:05:00

      The time is right, but LocalTime's toString omits the seconds when they are zero.

   3. C. Compilation fails

      plusMinutes is a genuine LocalTime method and the code is well formed.

   4. D. 10:05Correct answer

      60 minutes past 9:05 is 10:05 — minutes carry into hours — and toString omits the zero seconds (JavaDoc 8 — LocalTime).

   Explanation

   60 minutes past 9:05 is 10:05 — minutes carry into hours automatically (not `09:65`). LocalTime's toString omits the seconds when they are zero (not `10:05:00`).

4. Question 4

   What is the output of the following program? ```java import java.time.LocalDate; import java.time.format.DateTimeFormatter; public class Main { public static void main(String[] args) { DateTimeFormatter f = DateTimeFormatter.ofPattern("MM-dd-yyyy"); System.out.println(f.format(LocalDate.of(2025, 7, 4))); } } ```

   1. A. 07-04-2025Correct answer

      MM is the zero-padded month and dd the zero-padded day, so July 4 renders as 07-04-2025 in the requested pattern order.

   2. B. 04-07-2025

      This swaps month and day; the pattern places MM first, so the month 07 leads and the day 04 follows.

   3. C. 7-4-2025

      Unpadded single digits would require single M and d in the pattern; MM and dd force two-digit zero padding to 07 and 04.

   4. D. 2025-07-04

      This is the default ISO toString of the date; the explicit formatter overrides it with the MM-dd-yyyy layout.

   Explanation

   In patterns, MM is the zero-padded month and dd the zero-padded day: July 4 renders as 07-04-2025. `04-07-2025` swaps month and day; `7-4-2025` would need single M and d; `2025-07-04` is the default ISO toString, which the formatter replaces. (Watch case: mm means minutes!)

5. Question 5

   What is the output of the following program? ```java import java.time.LocalTime; import java.time.Period; import java.time.temporal.UnsupportedTemporalTypeException; public class Main { public static void main(String[] args) { try { LocalTime t = LocalTime.of(10, 0).plus(Period.ofDays(1)); System.out.println(t); } catch (UnsupportedTemporalTypeException e) { System.out.println("unsupported"); } } } ```

   1. A. unsupportedCorrect answer

      The code compiles, but at runtime a LocalTime has no date fields, so adding a day-based Period throws UnsupportedTemporalTypeException, which the catch handles by printing "unsupported".

   2. B. 10:00

      This assumes adding a day to a time-only value is silently ignored; instead the mismatch throws before any value is printed.

   3. C. Compilation fails because plus cannot take a Period

      plus accepts any TemporalAmount, and Period implements that interface, so the call compiles; the problem surfaces only at runtime.

   4. D. 34:00

      This treats a day as 24 hours added to a LocalTime; a LocalTime never exceeds 24 hours, and a date-based Period is not a supported unit here.

   Explanation

   It COMPILES — plus(TemporalAmount) accepts a Period (`Compilation fails because plus cannot take a Period` is wrong) — but at runtime a LocalTime has no date fields, so adding a day-based Period throws UnsupportedTemporalTypeException. Mixing date-based amounts with time-only objects is a runtime error, not a compile one.

6. Question 6

   What is the output of the following program? ```java import java.time.LocalDate; public class Main { public static void main(String[] args) { LocalDate d = LocalDate.of(2025, 1, 30).plusDays(3); System.out.println(d); } } ```

   1. A. 2025-02-02Correct answer

      plusDays rolls correctly across the month boundary: January has 31 days, so Jan 30 + 3 days lands on Feb 2, printed in the ISO yyyy-MM-dd form.

   2. B. 2025-01-33

      This assumes plusDays just bumps the day-of-month number without normalizing; the API never produces an impossible date like the 33rd — it rolls into the next month instead.

   3. C. 2025-03-02

      This overshoots by a whole month, as if the three-day addition skipped past February; adding 3 days to Jan 30 only reaches Feb 2.

   4. D. An exception is thrown at runtime

      Adding days across a month boundary is a normal, valid operation; nothing here throws.

   Explanation

   plusDays rolls across month boundaries correctly: Jan 30 + 3 days = Feb 2 (January has 31 days). The ISO toString form is yyyy-MM-dd. There's never an invalid date like Jan 33 (`2025-01-33`) — the API normalizes.

7. Question 7

   What is the output of the following program? ```java import java.time.LocalDate; import java.time.Period; public class Main { public static void main(String[] args) { Period p = Period.ofYears(1).ofMonths(2); LocalDate d = LocalDate.of(2025, 1, 1).plus(p); System.out.println(d); } } ```

   1. A. 2026-03-01

      This assumes the year and month accumulate into 1 year 2 months; because ofMonths is a static factory, the second call replaces the first rather than adding to it.

   2. B. Compilation fails because Period factory methods cannot be chained

      Calling a static method through an instance reference is legal Java (only a warning), so the chained call compiles.

   3. C. 2025-03-01Correct answer

      Because the second static factory replaces the first, p represents only 2 months; Jan 1 + 2 months = Mar 1, 2025.

   4. D. 2026-01-01

      This assumes only the 1-year component survives; in fact the ofMonths call wins, leaving a 2-month period.

   Explanation

   The notorious Period trap: ofYears and ofMonths are STATIC factories, so 'chaining' them compiles (via the instance, legal but warned) yet the second call simply REPLACES the first — p is just 2 months, not 1 year 2 months (`2026-03-01`). Jan 1 + 2 months = Mar 1. Combine components with Period.of(1, 2, 0) instead.

8. Question 8

   What is the output of the following program? ```java import java.time.LocalDate; public class Main { public static void main(String[] args) { LocalDate d = LocalDate.of(2025, 3, 10); d.plusYears(1); System.out.println(d.getYear()); } } ```

   1. A. 2025Correct answer

      java.time types are immutable, so plusYears returns a new LocalDate that is discarded here; d still refers to 2025-03-10, and getYear() reports 2025.

   2. B. 2026

      This assumes plusYears mutates d in place; because the result of the call is thrown away, the original date is unchanged.

   3. C. Compilation fails

      The code is well-formed — calling plusYears and ignoring its return value is legal, so it compiles cleanly.

   4. D. An exception is thrown at runtime

      The call simply returns a new (unused) value; nothing throws at runtime.

   Explanation

   All java.time types are IMMUTABLE: plusYears returns a new LocalDate, and here the result is discarded — exactly like String methods. d still refers to 2025-03-10, so getYear() is 2025. The fix is d = d.plusYears(1).