1

As per this question, I have calculated the days between two dates in java. The program is below

SimpleDateFormat myFormat = new SimpleDateFormat("dd MM yyyy");
String inputString1 = "23 01 1997";
String inputString2 = "27 04 1997";

try {
    Date date1 = myFormat.parse(inputString1);
    Date date2 = myFormat.parse(inputString2);
    long diff = date2.getTime() - date1.getTime();
    System.out.println ("Days: " + TimeUnit.DAYS.convert(diff, TimeUnit.MILLISECONDS));
} catch (ParseException e) {
    e.printStackTrace();
}

But I have got issues when the dates are in daylight saving time zone. Like EDT to EST. For example, when we calculate days between (MAR 01, 2017) to (MAR 30, 2017), the actual count should be 29 but the result of the above program is 28.

Community
  • 1
  • 1
  • Use LocalDate instead of Date – Yosef Weiner Mar 30 '17 at 10:42
  • use ZonedDateTime if you are working with java 8 – Sasikumar Murugesan Mar 30 '17 at 10:46
  • Your Question is not clear: Do you want to know the number of 24-hour periods of time between two moments? Or do you want to know the number of days elapsed between two dates? Not at all the same thing. One big difference: Daylight Saving Time has nothing to do with dates and whole days. – Basil Bourque Mar 30 '17 at 19:23
  • @BasilBourque Our production environment is Linux and machine local time zone is EST5EDT. And the logic of my program is, while creating the business object will initialize the Calendar Object with date (Mar 01, 2017) called start_date and after doing some business logic it will return another Calendar Object with date(Mar 01, 2017) called event_date. Now as per business logic need to calculate number of days between the start_date and event_date. To calculate the number of days between the start_date and event_date the logic applied is as follows – Sivisha Shankar Mar 31 '17 at 10:04
  • ((event_date.getTimeInMillis() - start_date.getTimeInMillis())/86400000) This gave wrong result and I have also tried.TimeUnit.DAYS.convert(event_date.getTimeInMillis() - start_date.getTimeInMillis(), TimeUnit.MILLISECONDS). This also gave wrong result as above. My finally work around is ((event_d ((event_date.getTimeInMillis()/86400000 - start_date.getTimeInMillis()/86400000)). This worked without issue. – Sivisha Shankar Mar 31 '17 at 10:04

3 Answers3

2

You can use LocalDate for that:

System.out.println(
        Period.between(
                LocalDate.parse("2017-03-01"), 
                LocalDate.parse("2017-03-30")
        ).getDays()
); // 29

or using dd M yyyy format:

DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("dd M yyyy");
LocalDate localDate = LocalDate.parse("01 03 2017",dateTimeFormatter);
LocalDate localDate1 = LocalDate.parse("30 03 2017",dateTimeFormatter);
System.out.println(Period.between(localDate,localDate1).getDays());
Anton Balaniuc
  • 10,889
  • 1
  • 35
  • 53
0

Using java 8 new Date Time APi

    import java.time.*;
    import java.time.temporal.*;

    ZonedDateTime z1 = date1.toInstant().atZone(ZoneId.systemDefault());
    ZonedDateTime z2 = date2.toInstant().atZone(ZoneId.systemDefault());
    long diff = ChronoUnit.DAYS.between(z1, z2);  // 29
Sharon Ben Asher
  • 13,849
  • 5
  • 33
  • 47
  • Thanks @Sharon. This code gives expected output in java 8, but I am using java 6 and found an alternate way to solve the issue. date2.getTime()/86400000 - date1.getTime()/86400000 – Sivisha Shankar Mar 30 '17 at 12:08
  • @SivishaShankar The old legacy date-time classes are a bloody mess; avoid them. Use the java.time classes instead, as they were invented to supplant the legacy classes. Much of the java.time functionality is back-ported to Java 6 & 7 in [ThreeTen-Backport](http://www.threeten.org/threetenbp/) and further adapted to Android in [ThreeTenABP](https://github.com/JakeWharton/ThreeTenABP). – Basil Bourque Mar 30 '17 at 19:21
-1

Possibly what you need is to convert the dates into same timezone before you do a diff on it. The timezone code should look something like this -

myFormat.setTimeZone(TimeZone.getTimeZone("EST"));

PankajT
  • 145
  • 3