This is one of the (many) cases where java.time, the modern Java date and time API, excels:
public static long differenceInMonths(LocalDate dateFrom, LocalDate dateTo) {
return ChronoUnit.MONTHS.between(dateFrom, dateTo);
}
Yes, I seriously suggest that you use this in your old Java 6 code. It requires a little more explanation, of course. Before I get to that, allow me to demonstrate that the one-liner above gives you the results you expect:
LocalDate currentDate = LocalDate.of(2018, Month.AUGUST, 8);
System.out.println("1. Months until Aug 13 2018: "
+ differenceInMonths(currentDate, LocalDate.of(2018, Month.AUGUST, 13)));
System.out.println("2. Months until Oct 14 2018: "
+ differenceInMonths(currentDate, LocalDate.of(2018, Month.OCTOBER, 14)));
System.out.println("3. Months until Jan 03 2019: "
+ differenceInMonths(currentDate, LocalDate.of(2019, Month.JANUARY, 3)));
System.out.println("4. Months until Aug 03 2019: "
+ differenceInMonths(currentDate, LocalDate.of(2019, Month.AUGUST, 3)));
Output:
1. Months until Aug 13 2018: 0
2. Months until Oct 14 2018: 2
3. Months until Jan 03 2019: 4
4. Months until Aug 03 2019: 11
Question: How can I use this method when I have variables of type Date?
As I understand, you have an old method taking two old-fashioned Date arguments and you are asking why it gives incorrect results. So I guess you will also want to fix it to give the results that are considered correct by your users (as your own answer suggests). So rewrite your method to use my method above:
public static Integer getDiffMonths(Date dateFrom, Date dateTo) {
ZoneId zone = ZoneId.systemDefault();
LocalDate localDateFrom = DateTimeUtils.toInstant(dateFrom)
.atZone(zone)
.toLocalDate();
LocalDate localDateTo = DateTimeUtils.toInstant(dateTo)
.atZone(zone)
.toLocalDate();
long diff = differenceInMonths(localDateFrom, localDateTo);
if (diff < Integer.MIN_VALUE || diff > Integer.MAX_VALUE) {
throw new IllegalArgumentException("Dates are too far apart");
}
return (int) diff;
}
Even though the conversions from Date to LocalDate are at least as wordy as the conversions to Calendar in your own code, you may consider it worth is when the difference calculation itself is so simple and clear.
What went wrong in your old code has been explained nicely by others, there is no reason for me to repeat.
Question: How can I use java.time on Java 6?
java.time works nicely on Java 6.
- In Java 8 and later and on newer Android devices (from API level 26, I’m told) the modern API comes built-in.
- In Java 6 and 7 get the ThreeTen Backport, the backport of the new classes (ThreeTen for JSR 310; see the links at the bottom).
- On (older) Android use the Android edition of ThreeTen Backport. It’s called ThreeTenABP. And make sure you import the date and time classes from
org.threeten.bp with subpackages.
The code above uses ThreeTen Backport and imports the date and time classes from org.threeten.bp with subpackages:
import org.threeten.bp.DateTimeUtils;
import org.threeten.bp.LocalDate;
import org.threeten.bp.Month;
import org.threeten.bp.ZoneId;
import org.threeten.bp.temporal.ChronoUnit;
If you want to use the same code on Java 8 or later and use the built-in java.time, the conversion happens a little differently, for example:
LocalDate localDateFrom = dateFrom.toInstant()
.atZone(zone)
.toLocalDate();
Links
