Manipulate date, time, duration, period, instant and time-zone objects including daylight saving time using Date-Time API.
1. The correct answer is D.
Explanation:
LocalDate.of(2014);
LocalDate.of() method requires a year, month, and day to be specified. Providing only a year will result in a compilation error.LocalDate.with(2014, 1, 30);
LocalDate class does not have a with() method that takes three int arguments for year, month, and day. The correct method to use is LocalDate.of(int year, int month, int dayOfMonth).LocalDate.of(2014, 0, 30);
LocalDate class are indexed starting from 1. Valid month values are from 1 to 12, so using 0 will throw a DateTimeException.LocalDate.now().plusDays(5);
LocalDate.now() and then adds 5 days to it using the plusDays() method. This will create a new LocalDate object representing the date 5 days from now.2. The correct answer is C.
Explanation:
LocalDate instance representing 2014-01-02
atTime method does not return a LocalDate, but rather combines the LocalDate with the provided time parameters to create a LocalDateTime object.LocalTime instance representing 14:30:59:999999
atTime method does not return a LocalTime, but rather combines the LocalDate with the provided time parameters to create a LocalDateTime object. Additionally, LocalTime does not have nanosecond precision, so 999999 nanoseconds would be an invalid LocalTime.LocalDateTime instance representing 2014-01-02 14:30:59:999999
atTime method takes a LocalDate and combines it with the provided hour, minute, second, and nanosecond parameters to create a LocalDateTime object representing that date and time. The resulting LocalDateTime will be 2014-01-02 14:30:59:999999.LocalDate will not throw an exception.3. The correct answers are B and D.
Explanation:
YEAR
YEAR is not a valid ChronoUnit for LocalTime. LocalTime represents a time of day without any date information, so units of YEAR do not apply.NANOS
NANOS is a valid ChronoUnit for LocalTime. LocalTime has nanosecond precision, so you can perform operations on LocalTime using the NANOS unit.DAY
DAY is not a valid ChronoUnit for LocalTime. Similar to YEAR, LocalTime has no concept of days since it only represents a time, not a date.HALF_DAYS
HALF_DAYS is a valid ChronoUnit for LocalTime. A day can be divided into two 12-hour periods (AM and PM), so HALF_DAYS can be used with LocalTime to represent a difference or addition of 12 hour chunks of time.4. The correct answers are B and C.
Explanation:
java.time.Period implements java.time.temporal.Temporal
java.time.Period does not implement the java.time.temporal.Temporal interface. Period represents a span of time between two dates and is not itself a temporal object.java.time.Instant implements java.time.temporal.Temporal
java.time.Instant does implement the java.time.temporal.Temporal interface. Instant represents a point in time on the timeline and can be thought of as a temporal object.LocalDate and LocalTime are thread-safe.
LocalDate and LocalTime are indeed thread-safe. All the core Java Time classes, including LocalDate, LocalTime, LocalDateTime, Instant, etc., are designed to be immutable and thread-safe.LocalDateTime.now() will return the current time in UTC zone
LocalDateTime.now() returns the current date and time using the system clock in the default time zone, not necessarily in the UTC zone. To get the current time in UTC, you would use LocalDateTime.now(ZoneOffset.UTC) or Instant.now().5. The correct answer is A.
Explanation:
int nanos = i.getNano();
Instant class does have a getNano() method that returns the nanosecond part of the Instant as an int. This is a valid way to get the nanoseconds.long nanos = i.get(ChronoField.NANOS);
get(TemporalField) method of Instant to get the value of a specific ChronoField. Passing ChronoField.NANO_OF_SECOND (not ChronoField.NANO) will return the nanosecond part of the Instant as a long.long nanos = i.get(ChronoUnit.NANOS);
Instant does have a get(TemporalUnit) method, ChronoUnit.NANOS is not a valid argument for it. ChronoUnit values are used for durations and periods, not for fields of a temporal object.int nanos = i.getEpochNano();
Instant class does have a getEpochSecond() method that returns the number of seconds since the Unix epoch, but there is no corresponding getEpochNano() method.6. The correct answer is D.
Explanation:
P29D
Period.between method calculates the period between the second date and the first date, in that order. Since the first date (2025-03-20) is later than the second date (2025-02-20), the resulting period will be negative, not positive.P-29D
-29D. A Period first counts the number of complete months, then the remaining days.P1M
P-1M
Period.between method subtracts the second date from the first date. In this case, 2025-03-20 minus 2025-02-20 results in a period of -1 month, which is represented as P-1M. The Period class first calculates the difference in complete months, and then any remaining days. Since the difference is exactly one month, the result is P-1M.7. The correct answer is D.
Explanation:
PT5M
PT5M represents a duration of 5 minutes, which would be the result if the second time point was 5 minutes after the first. However, since LocalTime.of(18, 5) is being compared to a LocalDateTime, this causes an issue because they are not of the same type.PT-5M
PT-5M represents a duration of negative 5 minutes. Similar to option A, this would only be the case if the second time point was before the first. The main issue is that there is a type mismatch between LocalDateTime and LocalTime.PT300S
PT300S represents a duration of 300 seconds (or 5 minutes), which again would be the result if the second time point was 5 minutes after the first. However, this still doesn’t resolve the type mismatch issue between LocalDateTime and LocalTime.LocalDateTime.of(2025, 3, 20, 18, 0) and LocalTime.of(18, 5). The Duration.between method requires two temporal objects of the same type.8. The correct answers are A and C.
Explanation:
DAY_OF_WEEK
DAY_OF_WEEK is a valid ChronoField value for LocalDate. It represents the day of the week, an integer from 1 (Monday) to 7 (Sunday), which can be extracted from a LocalDate.HOUR_OF_DAY
HOUR_OF_DAY is not a valid ChronoField value for LocalDate. HOUR_OF_DAY pertains to LocalTime or LocalDateTime, which include time components, whereas LocalDate only deals with date components.DAY_OF_MONTH
DAY_OF_MONTH is a valid ChronoField value for LocalDate. It represents the day of the month, which can be extracted from a LocalDate.MILLI_OF_SECOND
MILLI_OF_SECOND is not a valid ChronoField value for LocalDate. MILLI_OF_SECOND pertains to time components, specifically for LocalTime or LocalDateTime, and LocalDate only deals with date components.9. The correct answer is C.
Explanation:
ZoneId.ofHours(2);
ofHours(int) belongs to the ZoneOffset class, not ZoneId.ZoneId.of("2");
ZoneId. It should be a proper time-zone ID or start with a sign (+ or -).ZoneId.of("-1");
ZoneId.of("-1") is valid since it follows the correct format for time-zone offsets.ZoneId.of("America/Canada");
"Area/City" format, not "Area/Country". A valid example would be "America/Montreal".10. The correct answer is D.
Explanation:
0
offset.get(ChronoField.HOUR_OF_DAY) does not return the hour value of the ZoneOffset. ZoneOffset represents a time-zone offset from UTC/Greenwich, and calling get(ChronoField.HOUR_OF_DAY) on it is not appropriate.1
get method of ZoneOffset with ChronoField.HOUR_OF_DAY does not produce this result. The ZoneOffset class is not meant to provide such a field directly.12:00
12:00 is not a valid response for the method call as it implies a time representation, while ZoneOffset is dealing with offset values rather than specific time of day values.ZoneOffset does not support the field ChronoField.HOUR_OF_DAY. The ZoneOffset class provides offset values in terms of seconds rather than specific chrono fields like hour of day.11. The correct answer is A.
Explanation:
05:00
ZonedDateTime.of(2025, 02, 28, 5, 0, 0, 0, ZoneId.of("+05:00")) creates a ZonedDateTime instance with the specified date, time, and time zone offset of +05:00. Calling toLocalTime() on this instance returns the local time, which is 05:00, as no conversion to the local time zone of +2:00 is done in this code snippet.17:00
17:00 would be the time if the code converted the given time (05:00) from the +05:00 time zone to the local time zone of +02:00, which it does not.02:00
02:00 does not correspond to any logical result based on the given time and time zone offset.03:00
03:00 also does not correspond to any logical result based on the given time and time zone offset.12. The correct answer is C.
Explanation:
2025-10-04T00:00-03:00[America/Asuncion]
2025-10-04T00:00-03:00[America/Asuncion] before DST starts. When 1 hour is added, the time will shift forward by 1 hour, but since DST starts at this moment, the offset will change.2025-10-04T01:00-03:00[America/Asuncion]
2025-10-04T00:00-03:00[America/Asuncion] while considering the start of DST (which typically adds 1 hour to the local time) means that the effective time would be adjusted by the DST transition.2025-10-04T02:00-03:00[America/Asuncion]
2025-10-04T00:00-03:00[America/Asuncion]. With the addition of 1 hour and considering the DST start at 2025-10-04T00:00, the time advances to 2025-10-04T02:00-03:00[America/Asuncion], as it effectively skips the 01:00 hour.2025-10-03T23:00-03:00[America/Asuncion]
2025-10-03T23:00-03:00[America/Asuncion] does not correlate correctly with the 1 hour addition from the initial time and does not account for the DST transition.13. The correct answer is B.
Explanation:
java.time.ZoneOffset is a subclass of java.time.ZoneId.
java.time.ZoneOffset is not a subclass of java.time.ZoneId. java.time.ZoneOffset is a final class that extends java.time.ZoneId but it is not a subclass.java.time.Instant can be obtained from java.time.ZonedDateTime.
java.time.Instant can indeed be obtained from java.time.ZonedDateTime using the toInstant() method.java.time.ZoneOffset can manage DST.
java.time.ZoneOffset represents a fixed offset from UTC and does not manage Daylight Saving Time (DST). DST is managed by java.time.ZoneId.java.time.OffsetDateTime represents a point in time in the UTC time zone.
java.time.OffsetDateTime represents a date-time with an offset from UTC, but it does not necessarily represent a point in the UTC time zone. The offset can be any valid ZoneOffset.14. The correct answer is C.
Explanation:
5/7/15 4:00 PM
DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT) method is used to format only the time portion of a LocalDateTime object, and it does not include the date. Therefore, the output will not include 5/7/15.5/7/15
DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT) formats only the time portion and does not include the date. Thus, the output 5/7/15 is not possible.4:00 PM
DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT) formats the time portion of the LocalDateTime object in a short style. Given the input time 16:00, in the Locale.ENGLISH, the formatted output is 4:00 PM.4:00:00 PM
DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT) formats the time portion without including seconds. Therefore, the output will not include 4:00:00 PM.15. The correct answer is D.
Explanation:
HH:mm:ss X is invalid.
HH:mm:ss X is valid. HH represents the hour of the day (00-23), mm represents the minute of the hour, ss represents the second of the minute, and X represents the ISO 8601 time zone offset.OffsetDateTime is created successfully.
HH:mm:ss X is valid, but the OffsetDateTime.parse method requires a date and time format along with the offset. Since the input string "11:50:20 Z" does not contain a date part, this will cause a DateTimeParseException.Z is an invalid offset.
Z is a valid offset representing UTC (Coordinated Universal Time)."11:50:20 Z" does not match the expected pattern for an OffsetDateTime, which typically includes a date part as well as the time and offset.Do you like what you read? Would you consider?
Do you have a problem or something to say?