Date/Time API (JSR-310) practice questions

From OCP Java SE 8 (1Z0-809) · 17 questions on this topic

Date/Time API (JSR-310) practice questions from OCP Java SE 8 (1Z0-809). This pack has 17 questions tagged Date/Time API (JSR-310), drawn from its timed mock exams. 8 of them are worked through in full below — the question, every option, why each is right or wrong, and the explanation.

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

  1. Question 1

    What is the output of the following program? ```java import java.time.Duration; import java.time.LocalTime; public class Main { public static void main(String[] args) { Duration d = Duration.between( LocalTime.of(9, 0), LocalTime.of(11, 30)); System.out.println(d); } } ```

    1. A. Compilation fails because Duration requires LocalDateTime arguments

      Duration.between works with LocalTime; it does not require LocalDateTime.

    2. B. 02:30

      Duration prints in ISO-8601 duration form, not as a clock time.

    3. C. PT2H30MCorrect answer

      Correct: the two-and-a-half-hour gap prints with the mandatory PT prefix.

    4. D. P2H30M

      The T separating date and time components is mandatory before the hours; dropping it is invalid.

    Explanation

    Duration measures a time-based amount and prints in ISO-8601 with a PT prefix. Duration.between accepts any time-capable temporal, so two LocalTime values are valid arguments.

  2. Question 2

    In America/New_York, daylight saving time begins on 2026-03-08: clocks jump from 2:00 to 3:00. What is the output of the following program? ```java import java.time.ZoneId; import java.time.ZonedDateTime; public class Main { public static void main(String[] args) { ZoneId ny = ZoneId.of("America/New_York"); ZonedDateTime before = ZonedDateTime.of(2026, 3, 8, 1, 30, 0, 0, ny); ZonedDateTime after = before.plusHours(1); System.out.println(after.toLocalTime()); } } ```

    1. A. 02:30

      This is the result you would get without daylight saving, treating the addition as a plain wall-clock hour; it ignores that the 2:00 to 3:00 hour is skipped that night.

    2. B. 03:30Correct answer

      plusHours adds one real elapsed hour, and because the 2:00 to 3:00 wall-clock hour does not exist when DST begins, the local time lands at 3:30 (JavaDoc 8, ZonedDateTime DST handling).

    3. C. An exception is thrown because 2:30 does not exist

      Arithmetic across the spring-forward gap does not throw; ZonedDateTime resolves it silently using the zone rules, so no exception occurs.

    4. D. 01:30

      This is the starting time left unchanged, which fails to add the hour at all.

    Explanation

    plusHours adds one real elapsed hour rather than merely bumping the wall-clock reading. Because the 2:00 to 3:00 hour does not exist on the night daylight saving begins, the resulting local time is 3:30 instead of 2:30. ZonedDateTime navigates the gap automatically using the zone rules, without throwing.

  3. Question 3

    In America/New_York, clocks fall back from 02:00 EDT to 01:00 EST on 2026-11-01. What is the output of the following program? ```java import java.time.LocalDateTime; import java.time.ZoneId; import java.time.ZonedDateTime; public class Main { public static void main(String[] args) { ZonedDateTime start = ZonedDateTime.of( LocalDateTime.of(2026, 11, 1, 0, 30), ZoneId.of("America/New_York")); ZonedDateTime later = start.plusHours(2); System.out.println(later.toLocalTime()); } } ```

    1. A. 02:30

      This is what a day without a transition would give; the overlap repeats an hour.

    2. B. 03:30

      This overshoots; the fall-back repeats the hour rather than skipping ahead.

    3. C. 01:30Correct answer

      Correct: two elapsed hours cross the fall-back point, landing on the repeated instance of this wall-clock time.

    4. D. 00:30

      This is earlier than the start plus two hours; time moves forward, not back to the origin.

    Explanation

    Adding hours to a zoned time advances by real elapsed time, and during a fall-back overlap the wall clock repeats an hour. Two real hours across the transition land on a repeated wall-clock time.

  4. Question 4

    What is the output of the following program? ```java import java.time.Instant; import java.time.temporal.ChronoUnit; public class Main { public static void main(String[] args) { Instant i = Instant.ofEpochSecond(0).plus(2, ChronoUnit.DAYS); System.out.println(i); } } ```

    1. A. 1970-01-03T00:00:00ZCorrect answer

      Correct: two days after the epoch start lands on this instant, printed with the UTC marker.

    2. B. 1970-01-03T00:00:00 without a zone marker

      Instant always prints with the Z zone marker.

    3. C. An UnsupportedTemporalTypeException is thrown because Instant does not support DAYS

      Instant does support DAYS as a fixed twenty-four-hour unit; only estimated units like months or years are rejected.

    4. D. 1970-01-02T00:00:00Z

      This adds only one day; two days advance the date further.

    Explanation

    The epoch second zero is the start of 1970, and adding whole days advances the date accordingly. Instant supports DAYS as exactly twenty-four hours and always renders with a trailing Z.

  5. Question 5

    What is the output of the following program? ```java import java.time.LocalDate; public class Main { public static void main(String[] args) { System.out.println(LocalDate.of(2026, 6, 5).getDayOfWeek()); } } ```

    1. A. Compilation fails because months are zero-based

      java.time months are one-based, so there is no zero-based month error.

    2. B. Fri

      The enum's toString is the full constant name, not a localized short form.

    3. C. 5

      A numeric day-of-week comes from getValue, not from the enum's toString.

    4. D. FRIDAYCorrect answer

      Correct: getDayOfWeek returns the enum constant, printed as its uppercase name.

    Explanation

    getDayOfWeek returns a DayOfWeek enum whose toString is the constant's uppercase name. java.time months are one-based, so the numeric month maps directly to its calendar month.

  6. Question 6

    What is the output of the following program? ```java import java.time.LocalDate; import java.time.temporal.ChronoUnit; public class Main { public static void main(String[] args) { System.out.println(ChronoUnit.DAYS.between(LocalDate.of(2026, 1, 1), LocalDate.of(2026, 2, 1))); } } ```

    1. A. 1

      This is the count in months, not days; measuring the same span with ChronoUnit.MONTHS gives 1, but the code asks for DAYS.

    2. B. 31Correct answer

      ChronoUnit.DAYS.between counts whole days from the start date inclusive to the end date exclusive, and January has 31 days, so the result is 31.

    3. C. 30

      This undercounts by one, as if a boundary day were dropped; the full length of January is 31 days.

    4. D. 32

      This overcounts by one; between is exclusive of the end date, so February 1 itself is not counted.

    Explanation

    ChronoUnit.DAYS.between measures whole days from the start date, inclusive, to the end date, exclusive. From January 1 to February 1 spans the full length of January, which has 31 days. Measuring the same interval in months would instead yield one.

  7. Question 7

    What is the output of the following program? ```java import java.time.LocalDateTime; import java.time.ZoneId; import java.time.ZonedDateTime; public class Main { public static void main(String[] args) { ZonedDateTime z = LocalDateTime.of(2026, 1, 15, 12, 0).atZone(ZoneId.of("America/New_York")); System.out.println(z.toInstant()); } } ```

    1. A. 2026-01-15T17:00:00ZCorrect answer

      In January New York is on standard time at offset -05:00, so noon local is 17:00 UTC; toInstant applies that offset to give 2026-01-15T17:00:00Z.

    2. B. Compilation fails because LocalDateTime has no zone to convert from

      atZone is precisely how a LocalDateTime acquires a zone and becomes a ZonedDateTime, so the code compiles.

    3. C. 2026-01-15T07:00:00Z

      This applies the offset in the wrong direction, subtracting instead of adding five hours; converting local time to UTC in a negative-offset zone moves the clock forward.

    4. D. 2026-01-15T12:00:00Z

      This leaves the wall-clock time unchanged, forgetting that converting to an Instant shifts it by the zone's offset from UTC.

    Explanation

    Calling atZone attaches a time zone to a LocalDateTime, producing a ZonedDateTime, and toInstant then converts that to a UTC point in time. In January New York observes standard time at an offset of -05:00, so noon there corresponds to 17:00 UTC. Converting a local time in a negative-offset zone adds the offset rather than subtracting it, and it does not leave the wall-clock reading untouched.

  8. Question 8

    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(23, 30).plusHours(1); System.out.println(t); } } ```

    1. A. 23:30

      plusHours returns a new time that is assigned here, so the value does change.

    2. B. A DateTimeException is thrown at runtime

      The wrap-around is silent; no overflow exception is thrown.

    3. C. 24:30

      There is no hour 24; the clock rolls over to zero.

    4. D. 00:30Correct answer

      Correct: adding one hour to the given time wraps past midnight to this early time.

    Explanation

    LocalTime wraps silently around midnight, so adding past the end of the day rolls into the next day's early hours without error. The returned value is a new time that is assigned and printed.

Practise all 17 Date/Time API (JSR-310) questions

OCP Java SE 8 has the full set, inside timed mock exams that mirror real exam conditions — every question with a worked explanation.

Open OCP Java SE 8

Other topics in this pack