Develop Reference

Java 8 calculate months between two dates

NOTE THIS IS NOT A DUPLICATE OF EITHER OF THE FOLLOWING
Calculating the difference between two Java date instances
calculate months between two dates in java [duplicate]
I have two dates:
Start date: "2016-08-31"
End date: "2016-11-30"
Its 91 days duration between the above two dates, I expected my code to return 3 months duration, but the below methods only returned 2 months. Does anyone have a better suggestion? Or do you guys think this is a bug in Java 8? 91 days the duration only return 2 months.
Thank you very much for the help.
Method 1:
Period diff = Period.between(LocalDate.parse("2016-08-31"),
LocalDate.parse("2016-11-30"));
Method 2:
long daysBetween = ChronoUnit.MONTHS.between(LocalDate.parse("2016-08-31"),
LocalDate.parse("2016-11-30"));
Method 3:
I tried to use Joda library instead of Java 8 APIs, it works. it loos will return 3, It looks like Java duration months calculation also used days value. But in my case, i cannot use the Joda at my project. So still looking for other solutions.
LocalDate dateBefore= LocalDate.parse("2016-08-31");
LocalDate dateAfter = LocalDate.parse("2016-11-30");
int months = Months.monthsBetween(dateBefore, dateAfter).getMonths();
System.out.println(months);

Since you don't care about the days in your case. You only want the number of month between two dates, use the documentation of the period to adapt the dates, it used the days as explain by Jacob. Simply set the days of both instance to the same value (the first day of the month)
Period diff = Period.between(
LocalDate.parse("2016-08-31").withDayOfMonth(1),
LocalDate.parse("2016-11-30").withDayOfMonth(1));
System.out.println(diff); //P3M
Same with the other solution :
long monthsBetween = ChronoUnit.MONTHS.between(
LocalDate.parse("2016-08-31").withDayOfMonth(1),
LocalDate.parse("2016-11-30").withDayOfMonth(1));
System.out.println(monthsBetween); //3
Edit from #Olivier Grégoire comment:
Instead of using a LocalDate and set the day to the first of the month, we can use YearMonth that doesn't use the unit of days.
long monthsBetween = ChronoUnit.MONTHS.between(
YearMonth.from(LocalDate.parse("2016-08-31")),
YearMonth.from(LocalDate.parse("2016-11-30"))
)
System.out.println(monthsBetween); //3

Since Java8:
ChronoUnit.MONTHS.between(startDate, endDate);

//Backward compatible with older Java
public static int monthsBetween(Date d1, Date d2){
if(d2==null || d1==null){
return -1;//Error
}
Calendar m_calendar=Calendar.getInstance();
m_calendar.setTime(d1);
int nMonth1=12*m_calendar.get(Calendar.YEAR)+m_calendar.get(Calendar.MONTH);
m_calendar.setTime(d2);
int nMonth2=12*m_calendar.get(Calendar.YEAR)+m_calendar.get(Calendar.MONTH);
return java.lang.Math.abs(nMonth2-nMonth1);
}

The documentation of Period#between states the following:
The start date is included, but the end date is not.
Furthermore:
A month is considered if the end day-of-month is greater than or equal to the start day-of-month.
Your end day-of-month 30 is not greater than or equal to your start day-of-month 31, so a third month is not considered.
Note the parameter names:
public static Period between​(LocalDate startDateInclusive, LocalDate endDateExclusive)
To return 3 months, you can increment the endDateExclusive by a single day.

In case you want stick to java.time.Period API
As per java.time.Period documentation
Period between(LocalDate startDateInclusive, LocalDate endDateExclusive)
where
#param startDateInclusive the start date, inclusive, not null
#param endDateExclusive the end date, exclusive, not null
So it is better to adjust your implementation to make your end date inclusive and get your desired result
Period diff = Period.between(LocalDate.parse("2016-08-31"),
LocalDate.parse("2016-11-30").plusDays(1));
System.out.println("Months : " + diff.getMonths());
//Output -> Months : 3

You have to be careful, never use LocalDateTime to calculate months between two dates the result is weird and incorrect, always use LocalDate !
here's is some code to prove the above:
package stack.time;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.temporal.ChronoUnit;
public class TestMonthsDateTime {
public static void main(String[] args) {
/**------------------Date Time----------------------------*/
LocalDateTime t1 = LocalDateTime.now();
LocalDateTime t2 = LocalDateTime.now().minusMonths(3);
long dateTimeDiff = ChronoUnit.MONTHS.between(t2, t1);
System.out.println("diff dateTime : " + dateTimeDiff); // diff dateTime : 2
/**-------------------------Date----------------------------*/
LocalDate t3 = LocalDate.now();
LocalDate t4 = LocalDate.now().minusMonths(3);
long dateDiff = ChronoUnit.MONTHS.between(t4, t3);
System.out.println("diff date : " + dateDiff); // diff date : 3
}
}
My 2%

This example checks to see if the second date is the end of that month. If it is the end of that month and if the first date of month is greater than the second month date it will know it will need to add 1
LocalDate date1 = LocalDate.parse("2016-08-31");
LocalDate date2 = LocalDate.parse("2016-11-30");
long monthsBetween = ChronoUnit.MONTHS.between(
date1,
date2);
if (date1.isBefore(date2)
&& date2.getDayOfMonth() == date2.lengthOfMonth()
&& date1.getDayOfMonth() > date2.getDayOfMonth()) {
monthsBetween += 1;
}

After the short investigation, still not totally fix my question, But I used a dirty solution to avoid return the incorrect duration. At least, we can get the reasonable duration months.
private static long durationMonths(LocalDate dateBefore, LocalDate dateAfter) {
System.out.println(dateBefore+" "+dateAfter);
if (dateBefore.getDayOfMonth() > 28) {
dateBefore = dateBefore.minusDays(5);
} else if (dateAfter.getDayOfMonth() > 28) {
dateAfter = dateAfter.minusDays(5);
}
return ChronoUnit.MONTHS.between(dateBefore, dateAfter);
}

The Java API response is mathematically accurate according to the calendar. But you need a similar mechanism, such as rounding decimals, to get the number of months between dates that matches the human perception of the approximate number of months between two dates.
Period period = Period.between(LocalDate.parse("2016-08-31"), LocalDate.parse("2016-11-30"));
long months = period.toTotalMonths();
if (period.getDays() >= 15) {
months++;
}

Issues Converting String dates into Long values and performing calculations

I have a map of string values which represent down times for different components.
dependencyMap.put ("sut", "14:26:12,14:27:19,00:01:07;15:01:54,15:02:54,00:01:00;15:44:30,15:46:30,00:02:00;16:10:30,16:11:30,00:01:00");
dependencyMap.put ("jms", "14:26:12,14:28:12,00:02:00;15:10:50,15:12:55,00:02:05;15:42:30,15:43:30,00:01:00;16:25:30,16:27:30,00:02:00");
The strings represent the start, end and duration of down times.
(start)14:26:12,(end)14:27:19,(duration)00:01:07
I read the values in, then add them to a list of DependencyDownTime objects which hold the Long values startTime, endTime and duration.
jArray.forEach (dependency ->{
String downTimeValues = knownDowntimesMap.get(dependency);
final String[] downtime = downTimeValues.split (";");
for (final String str : downtime) {
final DependencyDownTime depDownTime = new DependencyDownTime ();
final String[] strings = str.split (",");
if (strings.length == 3) {
final DateFormat dateFormat = new SimpleDateFormat ("HH:mm:ss");
try {
depDownTime.setStartTime(dateFormat.parse (strings[0]).getTime ());
depDownTime.setEndTime (dateFormat.parse (strings[1]).getTime ());
depDownTime.setDuration (dateFormat.parse (strings[2]).getTime ());
downTimes.add (depDownTime);
} catch (final ParseException e) {
//logger.warn (e.getMessage (), e);
}
} else {
//logger.warn ("");
}
}
I then perform simple arithmetic on the values, which calculates the total down time for each component.
// sort the list by start time
Collections.sort(downTimes, Comparator.comparing (DependencyDownTime::getStartTime));
int i = 1;
Long duration = 0L;
for(DependencyDownTime dts: downTimes){
Long curStart = dts.getStartTime ();
Long curEnd = dts.getEndTime();
Long nextStart = downTimes.get(i).getStartTime ();
Long nextEnd = downTimes.get(i).getEndTime ();
if(duration == 0){
duration = dts.getDuration();
}
if(curStart.equals(nextStart) && curEnd < nextEnd){
duration += (nextEnd - curEnd);
}
else if(nextStart > curEnd){
duration += downTimes.get(i).getDuration();
}
else if( curStart < nextStart && curEnd > nextStart){
duration += (nextEnd - curEnd);
}
else if(curEnd == nextStart){
duration += downTimes.get(i).getDuration();
}
i++;
if(i == downTimes.size ()){
componentDTimeMap.put (application, duration);
return;
}
The expected values should be something like 1970-01-01T 00:14:35 .000+0100, a matter of minutes. The actual result is usually extremely high off by a matter of hours in the difference 1969-12-31T 15:13:35 .000+0100
I have 2 questions.
Am I parsing the values correctly?
If my calculations are a little off when adding and subtracting the long values. When I convert the values back to Date format will there be a drastic difference in the expected value?

As explained in your other question, don't mistake those 2 different concepts:
a time of the day: it represents a specific point of a day, such as 10 AM or 14:45:50
a duration: it represents an amount of time, such as "1 hour and 10 minutes" or "2 years, 3 months and 4 days". The duration doesn't tell you when it starts or ends ("1 hour and 10 minutes" relative to what?), it's not attached to a chronology, it doesn't correspond to a specific point in the timeline. It's just the amount of time, by itself.
In your input, you have:
(start)14:26:12,(end)14:27:19,(duration)00:01:07
The start and end represents times of the day, and the duration represents the amount of time. SimpleDateFormat is designed to work with dates and times of the day, but not with durations. Treating the duration as a time of the day might work, but it's a hack as explained in this answer.
Another problem is that when SimpleDateFormat parses only a time, it defaults the day to January 1st 1970 at the JVM default timezone, leading to all the strange results you see. Unfortunately there's no way to avoid that, as java.util.Date works with full timestamps. A better alternative is to use the new date/time API.
As in your other question you're using Java 8, I'm assuming you can also use it here (but if you're using Java <= 7, you can use the ThreeTen Backport, a great backport for Java 8's new date/time classes. The only difference is the package names (in Java 8 is java.time and in ThreeTen Backport (or Android's ThreeTenABP) is org.threeten.bp), but the classes and methods names are the same).
As you're working only with times, there's no need to consider date fields (day/month/year), we can use a LocalTime instead. You can parse the strings directly, because they are in ISO861 compliant format:
LocalTime start = LocalTime.parse("14:26:12");
LocalTime end = LocalTime.parse("14:27:19");
Unfortunately there are no built-in parsers for a duration, so you'll have to parse it manually:
// parse the duration manually
String[] parts = "00:01:07".split(":");
Duration d = Duration
// get hours
.ofHours(Long.parseLong(parts[0]))
// plus minutes
.plusMinutes(Long.parseLong(parts[1]))
// plus seconds
.plusSeconds(Long.parseLong(parts[2]));
Another alternative is to remove the durations from your input (or ignore them) and calculate it using the start and end:
Duration d = Duration.between(start, end);
Both will give you a duration of 1 minute and 7 seconds.
My suggestion is to change the DependencyDownTime to store start and end as LocalTime objects, and the duration as a Duration object. With this, your algorithm would be like this:
Duration total = Duration.ZERO;
for (...) {
LocalTime curStart = ...
LocalTime curEnd = ...
LocalTime nextStart = ...
LocalTime nextEnd = ...
if (total.toMillis() == 0) {
duration = dts.getDuration();
}
if (curStart.equals(nextStart) && curEnd.isBefore(nextEnd)) {
total = total.plus(Duration.between(curEnd, nextEnd));
} else if (nextStart.isAfter(curEnd)) {
total = total.plus(downTimes.get(i).getDuration());
} else if (curStart.isBefore(nextStart) && curEnd.isAfter(nextStart)) {
total = total.plus(Duration.between(curEnd, nextEnd));
} else if (curEnd.equals(nextStart)) {
total = total.plus(downTimes.get(i).getDuration());
}
i++;
if (i == downTimes.size()) {
// assuming you want the duration as a total of milliseconds
componentDTimeMap.put(application, total.toMillis());
return;
}
}
You can either store the Duration object, or the respective value of milliseconds. Don't try to transform it to a Date, because a date is not designed nor supposed to work with durations. You can adapt this code to format a duration if you want (unfortunately there are no native formatters for durations).
Limitations
The code above assumes that all start and end times are in the same day. But if you have start at 23:50 and end at 00:10, should the duration be 20 minutes?
If that's the case, it's a little bit trickier, because LocalTime is not aware of the date (so it considers 23:50 > 00:10 and the duration between them is "minus 23 hours and 40 minutes").
In this case, you could do a trick and assume the dates are all at the current date, but when start is greater than end, it means that end time is in the next day:
LocalTime start = LocalTime.parse("23:50");
LocalTime end = LocalTime.parse("00:10");
// calculate duration
Duration d;
if (start.isAfter(end)) {
// start is after end, it means end is in the next day
// current date
LocalDate now = LocalDate.now();
// start is at the current day
LocalDateTime startDt = now.atTime(start);
// end is at the next day
LocalDateTime endDt = now.plusDays(1).atTime(end);
d = Duration.between(startDt, endDt);
} else {
// both start and end are in the same day
// just calculate the duration in the usual way
d = Duration.between(start, end);
}
In the code above, the result will be a Duration of 20 minutes.
Don't format dates as durations
Here are some examples of why SimpleDateFormat and Date aren't good to handle durations of time.
Suppose I have a duration of 10 seconds. If I try to transform it to a java.util.Date using the value 10 to a date (AKA treating a duration as a date):
// a 10 second duration (10000 milliseconds), treated as a date
Date date = new Date(10 * 1000);
System.out.println(date);
This will get a date that corresponds to "10000 milliseconds after unix epoch (1970-01-01T00:00Z)", which is 1970-01-01T00:00:10Z. But when I print the date object, the toString() method is implicity called (as explained here). And this method converts this millis value to the JVM default timezone.
In the JVM I'm using, the default timezone is America/Sao_Paulo, so the code above outputs:
Wed Dec 31 21:00:10 BRT 1969
Which is not what is expected: the UTC instant 1970-01-01T00:00:10Z corresponds to December 31st 1969 at 9 PM in São Paulo timezone.
This happens because I'm erroneously treating the duration as a date (and the output will be different, depending on the default timezone configured in the JVM).
A java.util.Date can't (must not) be used to work with durations. Actually, now that we have better API's, it should be avoided whenever possible. There are too many problems and design issues with this, just don't use it if you can.
SimpleDateFormat also won't work properly if you handle the durations as dates. In this code:
SimpleDateFormat dateFormat = new SimpleDateFormat("HH:mm:ss");
Date d = dateFormat.parse("10:00:00");
The input has only time fields (hour, minute and second), so SimpleDateFormat sets the date to January 1st 1970 at the JVM default timezone. If I System.out.println this date, the result will be:
Thu Jan 01 10:00:00 BRT 1970
That's January 1st 1970 at 10 AM in São Paulo timezone, which in UTC is equivalent to 1970-01-01T13:00:00Z - so d.getTime() returns 46800000.
If I change the JVM default timezone to Europe/London, it will create a date that corresponds to January 1st 1970 at 10 AM in London (or UTC 1970-01-01T09:00:00Z) - and d.getTime() now returns 32400000 (because 10 AM in London and 10 AM in São Paulo happened at different instants).
SimpleDateFormat isn't the right tool to work with durations - it isn't even the best tool to work with dates, actually.

Calcuting the date difference for a specified number of days using LocalDate class

I'm using openjdk version 1.8.0_112-release for development but will need to support previous JDK versions too (pre-Java-8) - so can't use java.time.
I am writing a utitily class to calculate the date to see if a saved date is before the current date which means its expired.
However, I am not sure I have done this the correct way. I am using LocalDate class to calculate the days. The expiration is counted starting from the date and time the user clicked save. That date will be saved and a check will be done against this saved date and time and the current date and time i.e. when the user logs in.
Is this the best way to do it? I would like to keep to the LocalDate class.
import org.threeten.bp.LocalDate;
public final class Utilities {
private Utilities() {}
public static boolean hasDateExpired(int days, LocalDate savedDate, LocalDate currentDate) {
boolean hasExpired = false;
if(savedDate != null && currentDate != null) {
/* has expired if the saved date plus the specified days is still before the current date (today) */
if(savedDate.plusDays(days).isBefore(currentDate)) {
hasExpired = true;
}
}
return hasExpired;
}
}
I'm using the class like this:
private void showDialogToIndicateLicenseHasExpired() {
final LocalDate currentDate = LocalDate.now();
final int DAYS_TO_EXPIRE = 3;
final LocalDate savedDate = user.getSavedDate();
if(hasDateExpired(DAYS_TO_EXPIRE, savedDate, currentDate)) {
/* License has expired, warn the user */
}
}
I am looking a solution that will take in account time zones. If a license was set to expire in 3 days, and the user was to travel to a different time zone. i.e. they could be ahead or behind based on hours. The license should still expire.

Your code is basically fine. I would do it basically the same way, just with a detail or two being different.
As Hugo has already noted, I would use java.time.LocalDate and drop the use of ThreeTen Backport (unless it is a specific requirement that your code can run on Java 6 or 7 too).
Time Zone
You should decide in which time zone you count your days. Also I would prefer if you make the time zone explicit in yout code. If your system will be used in your own time zone only, the choice is easy, just make it explicit. For example:
final LocalDate currentDate = LocalDate.now(ZoneId.of("Asia/Hong_Kong"));
Please fill in the relevant zone ID. This will also make sure the program works correctly even if one day it happens to run on a computer with an incorrect time zone setting. If your system is global, you may want to use UTC, for example:
final LocalDate currentDate = LocalDate.now(ZoneOffset.UTC);
You will want to do similarly when saving the date when the user clicked Save so your data are consistent.
72 hours
Edit: I understand from your comment that you want to measure 3 days, that is, 72 hours, from the save time to determine whether the license has expired. For this a LocalDate does not give you enough information. It is only a date without a clock time, like May 26 2017 AD. There are some other options:
Instant is a point in time (with nanosecond precision, even). This is the simple solution to make sure the expiration happens after 72 hours no matter if the user moves to another time zone.
ZonedDateTime represents both a date and a time and a time zone, like 29 May 2017 AD 19:21:33.783 at offset GMT+08:00[Asia/Hong_Kong]. If you want to remind the user when the saved time was, a ZonedDateTime will you allow you to present that information with the time zone in which the save date was calculated.
Finally OffsetDateTime would work too, but it doesn’t seem to give you much of the advantages of the two others, so I will not eloborate on this option.
Since an instant is the same in all time zones, you don’t specify a time zone when getting the current instant:
final Instant currentDate = Instant.now();
Adding 3 days to an Instant is a little different LocalDate, but the rest of the logic is the same:
public static boolean hasDateExpired(int days, Instant savedDate, Instant currentDate) {
boolean hasExpired = false;
if(savedDate != null && currentDate != null) {
/* has expired if the saved date plus the specified days is still before the current date (today) */
if (savedDate.plus(days, ChronoUnit.DAYS).isBefore(currentDate)) {
hasExpired = true;
}
}
return hasExpired;
}
The use of ZonedDateTime, on the other hand, goes exactly like LocalDate in the code:
final ZonedDateTime currentDate = ZonedDateTime.now(ZoneId.of("Asia/Hong_Kong"));
If you want the current time zone setting from the JVM where the program runs:
final ZonedDateTime currentDate = ZonedDateTime.now(ZoneId.systemDefault());
Now if you declare public static boolean hasDateExpired(int days, ZonedDateTime savedDate, ZonedDateTime currentDate), you may do as before:
/* has expired if the saved date plus the specified days is still before the current date (today) */
if (savedDate.plusDays(days).isBefore(currentDate)) {
hasExpired = true;
}
This will perform the correct comparison even if the two ZonedDateTime objects are in two different time zones. So no matter if the user travels to a different time zone, s/he will not get fewer nor more hours before the license expires.

You can use ChronoUnit.DAYS (in org.threeten.bp.temporal package, or in java.time.temporal if you use java 8 native classes) to calculate the number of days between the 2 LocalDate objects:
if (savedDate != null && currentDate != null) {
if (ChronoUnit.DAYS.between(savedDate, currentDate) > days) {
hasExpired = true;
}
}
Edit (after bounty explanation)
For this test, I'm using threetenbp version 1.3.4
As you want a solution that works even if the user is in a different timezone, you shouldn't use LocalDate, because this class doesn't handle timezone issues.
I think the best solution is to use the Instant class. It represents a single point in time, no matter in what timezone you are (at this moment, everybody in the world are in the same instant, although the local date and time might be different depending on where you are).
Actually Instant is always in UTC Time - a standard indepedent of timezone, so very suitable to your case (as you want a calculation independent of what timezone the user is in).
So both your savedDate and currentDate must be Instant's, and you should calculate the difference between them.
Now, a subtle detail. You want the expiration to happen after 3 days. For the code I did, I'm making the following assumptions:
3 days = 72 hours
1 fraction of a second after 72 hours, it's expired
The second assumption is important for the way I implemented the solution. I'm considering the following cases:
currentDate is less than 72 hours after savedDate - not expired
currentDate is exactly 72 hours after savedDate - not expired (or expired? see comments below)
currentDate is more than 72 hours after savedDate (even by a fraction of a second) - expired
The Instant class has nanosecond precision, so in case 3 I'm considering that it's expired even if it's 1 nanosecond after 72 hours:
import org.threeten.bp.Instant;
import org.threeten.bp.temporal.ChronoUnit;
public static boolean hasDateExpired(int days, Instant savedDate, Instant currentDate) {
boolean hasExpired = false;
if (savedDate != null && currentDate != null) {
// nanoseconds between savedDate and currentDate > number of nanoseconds in the specified number of days
if (ChronoUnit.NANOS.between(savedDate, currentDate) > days * ChronoUnit.DAYS.getDuration().toNanos()) {
hasExpired = true;
}
}
return hasExpired;
}
Note that I used ChronoUnit.DAYS.getDuration().toNanos() to get the number of nanoseconds in a day. It's better to rely on the API instead of having hardcoded big error-prone numbers.
I've made some tests, using dates in the same timezone and in different ones.
I used ZonedDateTime.toInstant() method to convert the dates to Instant:
import org.threeten.bp.ZoneId;
import org.threeten.bp.ZonedDateTime;
// testing in the same timezone
ZoneId sp = ZoneId.of("America/Sao_Paulo");
// savedDate: 22/05/2017 10:00 in Sao Paulo timezone
Instant savedDate = ZonedDateTime.of(2017, 5, 22, 10, 0, 0, 0, sp).toInstant();
// 1 nanosecond before expires (returns false - not expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 9, 59, 59, 999999999, sp).toInstant()));
// exactly 3 days (72 hours) after saved date (returns false - not expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 10, 0, 0, 0, sp).toInstant()));
// 1 nanosecond after 3 days (72 hours) (returns true - expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 10, 0, 0, 1, sp).toInstant()));
// testing in different timezones (savedDate in Sao Paulo, currentDate in London)
ZoneId london = ZoneId.of("Europe/London");
// In 22/05/2017, London will be in summer time, so 10h in Sao Paulo = 14h in London
// 1 nanosecond before expires (returns false - not expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 13, 59, 59, 999999999, london).toInstant()));
// exactly 3 days (72 hours) after saved date (returns false - not expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 14, 0, 0, 0, london).toInstant()));
// 1 nanosecond after 3 days (72 hours) (returns true - expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 14, 0, 0, 1, london).toInstant()));
PS: for case 2 (currentDate is exactly 72 hours after savedDate - not expired) - if you want this to be expired, just change the if above to use >= instead of >:
if (ChronoUnit.NANOS.between(savedDate, currentDate) >= days * ChronoUnit.DAYS.getDuration().toNanos()) {
... // it returns "true" for case 2
}
If you don't want nanosecond precision and just want to compare the days between the dates, you can do as in #Ole V.V's answer. I believe our answers are very similar (and I suspect that the codes are equivalent, although I'm not sure), but I haven't tested enough cases to check if they differ in any particular situation.

The Answer by Hugo and the Answer by Ole V.V. Are both correct, and the one by Ole V.V. is most important, as time zone is crucial to determine the current date.
Period
Another useful class for this work is the Period class. This class represents a span of time unattached to the timeline as a number of years, months, and days.
Note that this class is not appropriate to representing the elapsed time needed for this Question because this representation is "chunked" as years, then months, and then any remaining days. So if LocalDate.between( start , stop ) were used for an amount of several weeks, the result might be something like "two months and three days". Notice that this class does not implement the Comparable interface for this reason, as one pair of months cannot be said to be bigger or smaller than another pair unless we know which specific months are involved.
We can use this class to represent the two-day grace-period mentioned in the Question. Doing so makes our code more self-documenting. Better to pass around an object of this type than passing a mere integer.
Period grace = Period.ofDays( 2 ) ;
LocalDate start = LocalDate.of( 2017 , Month.JANUARY , 23 ).plusDays( grace ) ;
LocalDate stop = LocalDate.of( 2017 , Month.MARCH , 7 ) ;
We use ChronoUnit to calculate elapsed days.
int days = ChronoUnit.DAYS.between( start , stop ) ;
Duration
By the way, the Duration class is similar to Period in that it represents a span of time not attached to the timeline. But Duration represents a total of whole seconds plus a fractional second resolved in nanoseconds. From this you can calculate a number of generic 24-hour days (not date-based days), hours, minutes, seconds, and fractional second. Keep in mind that days are not always 24-hours long; here in the United States they currently may be 23, 24, or 25 hours long because of Daylight Saving Time.
This Question is about date-based days, not lumps of 24-hours. So the Duration class is not appropriate here.
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, and later
Built-in.
Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
The ThreeTenABP project adapts ThreeTen-Backport (mentioned above) for Android specifically.
See How to use ThreeTenABP….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.

I think much better to use this:
Duration.between(currentDate.atStartOfDay(), savedDate.atStartOfDay()).toDays() > days;
Duration class placed in java.time package.

As this question is not getting "enough responses", I have added another answer:
I have used "SimpleDateFormat.setTimeZone(TimeZone.getTimeZone("UTC"));" to set the timezone to UTC. So there is no longer a timezone (all Date / time will be set to UTC).
savedDate is set to UTC.
dateTimeNow is also set to UTC, with the number of expired "days" (negative number) added to dateTimeNow.
A new Date expiresDate uses the long milliseconds from dateTimeNow
Check if savedDate.before(expiresDate)
package com.chocksaway;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;
public class ExpiredDate {
private static final long DAY_IN_MS = 1000 * 60 * 60 * 24;
private static boolean hasDateExpired(int days, java.util.Date savedDate) throws ParseException {
SimpleDateFormat dateFormatUtc = new SimpleDateFormat("yyyy-MMM-dd HH:mm:ss");
dateFormatUtc.setTimeZone(TimeZone.getTimeZone("UTC"));
// Local Date / time zone
SimpleDateFormat dateFormatLocal = new SimpleDateFormat("yyyy-MMM-dd HH:mm:ss");
// Date / time in UTC
savedDate = dateFormatLocal.parse( dateFormatUtc.format(savedDate));
Date dateTimeNow = dateFormatLocal.parse( dateFormatUtc.format(new Date()));
long expires = dateTimeNow.getTime() + (DAY_IN_MS * days);
Date expiresDate = new Date(expires);
System.out.println("savedDate \t\t" + savedDate + "\nexpiresDate \t" + expiresDate);
return savedDate.before(expiresDate);
}
public static void main(String[] args) throws ParseException {
Calendar cal = Calendar.getInstance();
cal.add(Calendar.DATE, 0);
if (ExpiredDate.hasDateExpired(-2, cal.getTime())) {
System.out.println("expired");
} else {
System.out.println("not expired");
}
System.out.print("\n");
cal.add(Calendar.DATE, -3);
if (ExpiredDate.hasDateExpired(-2, cal.getTime())) {
System.out.println("expired");
} else {
System.out.println("not expired");
}
}
}
Running this code gives the following output:
savedDate Mon Jun 05 15:03:24 BST 2017
expiresDate Sat Jun 03 15:03:24 BST 2017
not expired
savedDate Fri Jun 02 15:03:24 BST 2017
expiresDate Sat Jun 03 15:03:24 BST 2017
expired
All dates / times are UTC. First is not expired. Second is expired (savedDate is before expiresDate).

KISS
public static boolean hasDateExpired(int days, java.util.Date savedDate) {
long expires = savedDate().getTime() + (86_400_000L * days);
return System.currentTimeMillis() > expires;
}
Works on old JRE's just fine. Date.getTime() gives milliseconds UTC, so timezone isn't even a factor. The magic 86'400'000 is the number of milliseconds in a day.
Instead of using java.util.Date you can simplify this further if you just use a long for savedTime.

I have built a simple utility class ExpiredDate, with a TimeZone (such as CET), expiredDate, expireDays, and differenceInHoursMillis.
I use java.util.Date, and Date.before(expiredDate):
To see if Date() multiplied by expiryDays plus (timezone difference multiplied by expiryDays) is before expiredDate.
Any date older than the expiredDate is "expired".
A new Date is created by adding (i) + (ii):
(i). I use the number of milliseconds in a day to (DAY_IN_MS = 1000 * 60 * 60 * 24) which is multiplied with the (number of) expireDays.
+
(ii). To deal with a different TimeZone, I find the number of milliseconds between the Default timezone (for me BST), and the TimeZone (for example CET) passed into ExpiredDate. For CET, the difference is one hour, which is 3600000 milliseconds. This is multiplied by the (number of) expireDays.
The new Date is returned from parseDate().
If the new Date is before the expiredDate -> set expired to True.
dateTimeWithExpire.before(expiredDate);
I have created 3 tests:
Set the expiry date 7 days, and expireDays = 3
Not expired (7 days is greater than 3 days)
Set the expiry date / time, and expireDays to 2 days
Not expired - because the CET timezone adds two hours (one hour per day) to the dateTimeWithExpire
Set the expiry date 1 days, and expireDays = 2 (1 day is less than 2 days)
expired is true
package com.chocksaway;
import java.text.ParseException;
import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;
public class ExpiredDate {
/**
* milliseconds in a day
*/
private static final long DAY_IN_MS = 1000 * 60 * 60 * 24;
private String timeZone;
private Date expiredDate;
private int expireDays;
private int differenceInHoursMillis;
/**
*
* #param timeZone - valid timezone
* #param expiredDate - the fixed date for expiry
* #param expireDays - the number of days to expire
*/
private ExpiredDate(String timeZone, Date expiredDate, int expireDays) {
this.expiredDate = expiredDate;
this.expireDays = expireDays;
this.timeZone = timeZone;
long currentTime = System.currentTimeMillis();
int zoneOffset = TimeZone.getTimeZone(timeZone).getOffset(currentTime);
int defaultOffset = TimeZone.getDefault().getOffset(currentTime);
/**
* Example:
* TimeZone.getTimeZone(timeZone) is BST
* timeZone is CET
*
* There is one hours difference, which is 3600000 milliseconds
*
*/
this.differenceInHoursMillis = (zoneOffset - defaultOffset);
}
/**
*
* Subtract a number of expire days from the date
*
* #param dateTimeNow - the date and time now
* #return - the date and time minus the number of expired days
* + (difference in hours for timezone * expiryDays)
*
*/
private Date parseDate(Date dateTimeNow) {
return new Date(dateTimeNow.getTime() - (expireDays * DAY_IN_MS) + (this.differenceInHoursMillis * expireDays));
}
private boolean hasDateExpired(Date currentDate) {
Date dateTimeWithExpire = parseDate(currentDate);
return dateTimeWithExpire.before(expiredDate);
}
public static void main(String[] args) throws ParseException {
/* Set the expiry date 7 days, and expireDays = 3
*
* Not expired
*/
Calendar cal = Calendar.getInstance();
cal.add(Calendar.DATE, -7);
ExpiredDate expired = new ExpiredDate("CET", cal.getTime(), 3);
Date dateTimeNow = new Date();
if (expired.hasDateExpired(dateTimeNow)) {
System.out.println("expired");
} else {
System.out.println("NOT expired");
}
/* Set the expiry date / time, and expireDays to 2 days
* Not expired - because the CET timezone adds two hours to the dateTimeWithExpire
*/
cal = Calendar.getInstance();
cal.add(Calendar.DATE, -2);
expired = new ExpiredDate("CET", cal.getTime(), 2);
dateTimeNow = new Date();
if (expired.hasDateExpired(dateTimeNow)) {
System.out.println("expired");
} else {
System.out.println("NOT expired");
}
/* Set the expiry date 1 days, and expireDays = 2
*
* expired
*/
cal = Calendar.getInstance();
cal.add(Calendar.DATE, -1);
expired = new ExpiredDate("CET", cal.getTime(), 2);
dateTimeNow = new Date();
if (expired.hasDateExpired(dateTimeNow)) {
System.out.println("expired");
} else {
System.out.println("NOT expired");
}
}
}

adding/removing days from date code fix needed

I have this code here:
public static String AddRemoveDays(String date, int days) throws ParseException
{
SimpleDateFormat k = new SimpleDateFormat("yyyyMMdd");
Date d = k.parse(date);
d = new Date(d.getTime() + days*86400000);
String time = k.format(d);
return time;
}
It take String formed "yyyyMMdd", and adds int days to it. It should work then the days is negative - then he would substract the days from the date. When it does it's math, it returns String formated "yyyyMMdd".
At least that is what it should do. It works for small numbers, but if I try to add (or remove), for example, a year (365 or -365), it returns wierd dates.
What's the problem?
Should I do it a completley another way?

d = new Date(d.getTime() + days*86400000);
If you multiply 86400000 by 365 integer cant hold it. Change 86400000 to Long
d = new Date(d.getTime() + days*86400000L);
and it will be fine.

Hard to say what's going on without specific dates.
If you're committed to doing this with the raw Java classes, you might want to look at using Calendar -e.g.
Calendar calendar = Calendar.getInstance();
calendar.setTime(d);
calendar.add(Calendar.DATE, days); // this supports negative values for days;
d = calendar.getTime();
That said, I would recommend steering clear of the java Date classes, and look to use jodaTime or jsr310 instead.
e.g. in jsr310, you could use a DateTimeFormatter and LocalDate:
DateTimeFormatter format = DateTimeFormatters.pattern("yyyyMMdd");
LocalDate orig = format.parse(dateString, LocalDate.rule());
LocalDate inc = orig.plusDays(days); // again, days can be negative;
return format.print(inc);

Time problem with this code

import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
public class test {
/*
* Calculate the difference between two date/times *
*
*/
private static long dateDiff(Date toDate, Date fromDate) {
Calendar cal = Calendar.getInstance();
cal.setTime(toDate);
long ms = cal.getTimeInMillis();
cal.setTime(fromDate);
ms -= cal.getTimeInMillis();
return ms;
}
public static void main(String[] args) {
SimpleDateFormat sdf = new SimpleDateFormat("hh:mm:ss");
Date d1 = null;
Date d2 = null;
try {
d1 = sdf.parse("11:00:00");
d2 = sdf.parse("10:00:00");
} catch (Exception e) {
e.printStackTrace();
}
long result = dateDiff(d1, d2);
Date time = new Date(result);
System.out.println(time);
}
}
When I run it I get this result :
Thu Jan 01 02:00:00 CET 1970
I would expect 1 hour difference ?! again a problem with Timezone??
Any idea how I can fix it.
thx all

I don't know what you expect this to do, but what you are actually doing is outputting the date corresponding to one hour after midnight on Jan 1 1970, using the default timezone.
You seem to want to Date to represent a duration (i.e. a number of seconds). It doesn't do that, and neither will the Date formatters render a Date as a duration.
I need the time difference between two Date fields and then put it in MySql (time format)
For what you are trying to do, you need calculate the duration value as a long, then use the java.sql.Time(long) constructor to create a Time object. You can either serialize this object using its toString() method or use it as a parameter in a JDBC prepared statement.
It turns out that my advice above is incorrect too.
Your real problem is that the SQL Time type is for representing times ... not durations. In fact, SQL does not have a dedicated duration type, so the best you can do is represent the duration as an integer number of seconds or milliseconds or whatever.
(For the more general case, the Joda Time libraries are generally thought to provide the best APIs for manipulating dates, times and related temporal values. But for this simple case, the standard J2SE libraries should suffice ... provided that you use them correctly.)

The problem is that a difference of two Date types can not be represented by another Date type.

Why don't you just take the milliseconds of both dates and substract them from each other?
Calendar cal = Calendar.getInstance();
cal.setTime(d1);
long d1ms = cal.getTimeInMillis();
cal.setTime(d2);
long d2ms = cal.getTimeInMillis();
long diffMs = d1ms - d2ms;
long diffHour = diffMs * 1000 * 60 * 60;

Hi try this setting timezone to GMT. Remove day, month in words in the resultant time difference. This method does nothing but assumes these many milliseconds since starting of time counter in java, which is 1st Jan 1970. So if your result says 3rd Jan 1970 means 3 days have passed since time counter started, which is perfect. You just need to interpret it properly, but formatting your answer
...
long result = dateDiff(d1, d2); //This is your code in main([])
SimpleDateFormat dateFormat = new SimpleDateFormat("HH:mm:ss SSS");
dateFormat.setTimeZone(TimeZone.getTimeZone("GMT"));
System.out.println(dateFormat.format(new Date(result )));