Calendar behavior is not compatible with LocalDate?

Question

Hi buddies I'm in a trouble trying to migrate a behavior from calendar to localdate.

payDate.set(Calendar.DAY_OF_MONTH,payDay)

Lets imagine that payDate had the current date, 2020-01-29

for business reasons payDay can had the value of 0, so, when the previous code line is executed with the previous scenario, the result is that payDate update the date to 2019-12-31, that is to say the the date back to the last day of the past month.

I'm not sure, the technical reason of this, if someone can explain to me this I'll be so thankful, I tried checking the java doc but it was not helpful.

So I need to replicate that behavior with LocalDate java library. From my point of view; the similar of set method from Calendar with the value of DAY_OF_MONTH in LocalDate is:

payDate.withDayOfMonth(payDay)

But when the below scenario is presented and payDay is equal to 0 I get an error:

java.time.DateTimeException: Invalid value for DayOfMonth (valid values 1 - 28/31): 0

Also I had some ideas about how can I get the same result of calendar in localDate when the rule comes on (if payDay is 0, return to the last day of previous month), but are too verbose.

If you know a similar behavior on LocalDate please help me. Thanks.

Answer 1

TL;DR: Use payDate = payDate.plusDays(payDay - payDate.getDayOfMonth());

---

The behavior of Calendar you're describing is documented in the javadoc:

Leniency

Calendar has two modes for interpreting the calendar fields, lenient and non-lenient. When a Calendar is in lenient mode, it accepts a wider range of calendar field values than it produces. When a Calendar recomputes calendar field values for return by get(), all of the calendar fields are normalized. For example, a lenient GregorianCalendar interprets MONTH == JANUARY, DAY_OF_MONTH == 32 as February 1.

When a Calendar is in non-lenient mode, it throws an exception if there is any inconsistency in its calendar fields. For example, a GregorianCalendar always produces DAY_OF_MONTH values between 1 and the length of the month. A non-lenient GregorianCalendar throws an exception upon calculating its time or calendar field values if any out-of-range field value has been set.

To show the effect of this, try setting the date of a Calendar to January 70, 2020:

Calendar cal = Calendar.getInstance();
cal.clear();
cal.set(2020, Calendar.JANUARY, 70);
System.out.println(new SimpleDateFormat("yyyy-MM-dd").format(cal.getTime()));

Output

2020-03-10

You would get the same result if you did:

cal.set(2020, Calendar.JANUARY, 1);
cal.add(Calendar.DAY_OF_MONTH, 69);

---

LocalDate is always non-lenient, so you can't set the day-of-month value to a value that is out-of-range. You can however get the same result as what Calendar does, by changing the operation to "add" instead of "set".

So, if you have a particular date, e.g. the 2020-01-29 date mentioned in the question, and you want to "set" the day-of-month value to 70 or 0, with same lenient overflow logic as Calendar has, do this:

LocalDate date = LocalDate.parse("2020-01-29");
date = date.plusDays(70 - date.getDayOfMonth());
System.out.println(date);

LocalDate date = LocalDate.parse("2020-01-29");
date = date.plusDays(0 - date.getDayOfMonth());
System.out.println(date);

Output

2020-03-10

2019-12-31

As you can see, date.plusDays(dayToSet - date.getDayOfMonth()) will give you the desired result.

Answer 2

Here’s how I would go about it:

    LocalDate payDate = LocalDate.now(); // or whatever
    int payDay = 0;
    if (payDay == 0) {
        // simulate `GregorianCalendar` behaviour: day 0 is the day before day 1
        payDate = payDate.withDayOfMonth(1).minusDays(1);
    } else {
        payDate = payDate.withDayOfMonth(payDay);
    }
    System.out.println(payDate);

When I ran the snippet just now, the output was the date you already mentioned:

2019-12-31

If we wanted it shorter, we could use payDate.withDayOfMonth(1).minusDays(1).plusDays(payDay) or the trick from Andreas’ answer, and we would not need the if statement. I would not, though. (1) It’s harder to read. (2) It doesn’t give the validation of payDay that comes for free in the snippet above.

The confusing behaviour of Calendar comes from not range checking the argument to set(). So day 0 of the month is the day before day 1 of the month. Day -1 would be the day before that, and so forth. It’s in this snippet from the documentation (or was supposed to be, at least):

When a Calendar is in lenient mode, it accepts a wider range of calendar field values than it produces. When a Calendar recomputes calendar field values for return by get(), all of the calendar fields are normalized. For example, a lenient GregorianCalendar interprets MONTH == JANUARY, DAY_OF_MONTH == 32 as February 1.

You may read it with this snippet from the documentation of the setLenient method:

The default is lenient.

Links

• Documentation of Calendar
• Documentation of Calendar.setLenient()

Answer 3

You're not going to be able to just invoke one method to achieve the same results. If you're sure that setting DAY_OF_MONTH to 0 should cause it to roll back one month (this is the type of thing I'd run past a business analyst or product owner for a sanity check) then you're going to have to do something like this:

    int payDay = 0;
    LocalDate payDate = LocalDate.of(2020, Month.JANUARY, 29);

    if(payDay == 0) {
        payDate = payDate.minusMonths(1);
        payDay = payDate.lengthOfMonth();
    }

    payDate = payDate.withDayOfMonth(payDay);

Another approach:

   int payDay = 0;
   LocalDate payDate = LocalDate.of(2020, Month.JANUARY, 29);
   if(payDay == 0) {
      payDate = payDate.withDayOfMonth(1).minusDays(1);
   } else {
      payDate = payDate.withDayOfMonth(payDay);
   }