Quiz your self: The unusual case of the Java developer’s birthday

LocalDate birthday = LocalDate.now();

// line n1

DayOfWeek dow = birthday.getDayOfWeek();

Which two of the next might be added at line n1 to carry out this calculation? Select two.

A. birthday = birthday.plus(365, ChronoUnit.DAYS);

B. birthday.plus(365, ChronoUnit.DAYS);

C. birthday = birthday.plus(52, ChronoUnit.WEEKS);

D. birthday = birthday.plus(12, ChronoUnit.MONTHS);

E. birthday = birthday.plus(1, ChronoUnit.YEARS);

F. birthday.plusYears(1);

G. birthday.plus(1, ChronoUnit.YEARS);

Reply. This query investigates some easy guidelines associated to the Gregorian calendar and essential parts of the Date and Time API added with the discharge of Java 8.

First, think about the Gregorian calendar. Within the choices above, you might be supplied selections involving including three hundred and sixty five days, 52 weeks, 12 months, and 1 yr. Solely the final two are dependable, as a result of leap years have three hundred and sixty six days, and no yr has a full 52 weeks. So, you possibly can instantly reject choices A, B, and C as being incorrect from a logic perspective.

Choices D, E, F, and G all appear like they try so as to add both 12 months or 1 yr, so they appear plausible from the angle of enterprise logic. To maneuver ahead, although, you need to decide if the code is appropriate from the API perspective.

A key function of the Date and Time API is that the lessons inside it (with some exceptions, notably the exceptions it defines) are immutable. Which means that, as with the String class, if you invoke a way that adjustments a date-time ingredient, you don’t really change the contents of the prevailing object; as a substitute, you create a brand new object that represents the results of the change.

Due to this fact, if you happen to wrote this String code

String s = “Hiya”;

s.toUpperCase();

System.out.println(s);

the output could be Hiya since you did not retailer the uppercase String HELLO that was created within the second line. The identical error is made in choices F and G. Each of these choices accurately create a date precisely one yr sooner or later—however that object is misplaced, so the third line of the unique code pattern would nonetheless be working on as we speak’s date. From this you possibly can decide that choices F and G are each incorrect.

You now have solely two choices left: choices D and E. These are each appropriate from a enterprise logic perspective: They’re legitimate API strategies, and the brand new LocalDate object they create is correctly saved to be used on the ultimate line. From this you possibly can decide that choices D and E should be the right solutions.

Nonetheless, there’s one other wrinkle on this query, which explicitly mentions that it’s August. This has significance; that’s been ignored till now, however the logic given above isn’t full with out contemplating this.

When the developer runs the question on her birthday, if that day occurs to be February 29 (which signifies that the day is in a bissextile year) a call is pressured on the API. Clearly it might be an error if the end result had been February 29 within the following yr as a result of the next yr is not going to be a bissextile year. Due to this fact, the API would determine to deal with the end result as February 28 within the following yr. That call could also be arbitrary, nevertheless it’s documented and subsequently predictable.

That’s why, with no stipulation that precludes “as we speak” from being February 29, even choices D and E could be questionable—although they’d nonetheless be higher selections than the others. For those who encounter such a state of affairs in an examination, you’d be proper to decide on them within the absence of every other choices.

Conclusion. The right solutions are choices D and E.