Date/times logic in code is where the messiness of the real world upsets the relatively straightforward rules of the digital realm. Blame the bewildering hodgepodge of edge cases on the movement of celestial bodies and pope Gregory XIII (of the Gregorian calendar) but deal with it you must. I’m sure you all know that the 31st of December can be in week 52 or 53, while the 1st of January can be in week 0 or 1 and that you know these rules by heart for various countries (oh yes!). I’m also confident you can hand-code the logic to calculate the difference in seconds between two representations that span multiple time zones as well as a jump in daylight saving time.

Don’t Wait for the Next Leap Year

Forgive my sarcasm. Edge cases with time should be tested, especially if your code has homegrown date/time logic (which you should keep to a minimum). Application code deals with time representations that are either passed as one of the java.time classes, or as strings in some serialized format, e.g. 2022-12-03. For this category, you make up enough salient edges and make sure they are covered in unit tests. But often the code needs to know what the current time is. This new, unpredictable timestamp may just end up in a log statement, but it can also be the input to much more business-critical logic. Whenever you reference any of the *.now() methods, your program has introduced a side effect and become less deterministic.