为什么Java的Date.getTime（）会返回1月份的错误响应？

Question

The code for calculating the date in milliseconds is:

//installment date converted to milliseconds
long localDateInstall = installDate.getTime();

//installment date converted to milliseconds
long localDatePay = payDate.getTime();

and here I calculate the number of days between these dates:

days=Math.abs((localDatePay - localDateInstall))/86400000;

When I want to test it, I enter 1/Jan/2012 for localDateInstall and 1/Feb/2012 for localDatePay . The result is: 29 Days . What is the problem? Thanks

Answer 1

Counter-example:

public static void main(String[] args) throws Exception {
    SimpleDateFormat format = new SimpleDateFormat("d MMM yyyy");
    Date installDate = format.parse("1 Jan 2012");
    Date payDate = format.parse("1 Feb 2012");
    long localDatePay = payDate.getTime();
    long localDateInstall = installDate.getTime();
    long days = Math.abs(localDatePay - localDateInstall) / 86400000;
    System.out.println(days);
}

This works fine, and the output is "31", as expected. The problem is somewhere in what you haven't told us. Shot in the dark: you're probably constructing your test input like this:

Date installDate = new Date(2012, 1, 1);
Date payDate = new Date(2012, 2, 1);

Sadly, that's wrong in two ways. First, the "year" argument is supposed to be " the year minus 1900 ". Second, January is month 0, not month 1 . With those two dates as input, you would, indeed, get an answer of 29 because you're actually asking it for the number of days in February of 3912, which is a leap year.

Answer 2

You can try:

//installment date converted to milliseconds
long localDateInstall=installDate.getTimeInMillis();

//installment date converted to milliseconds
long localDatePay=payDate.getTimeInMillis();

long diff = localDatePay-localDateInstall;

long diffInDays = diff / (24 * 60 * 60 * 1000);    

Answer 3

I don't think there's enough information to go on, but here are some ideas to pursue.

1. You're performing integer arithmetic, which doesn't round, but rather truncates anything short of a whole day. If your end time of day is even a little earlier in the day than your start time, you'll lose a whole day.

2. Make sure there isn't something funny going on with the time zones. Are the two dates input in the same way, or are they coming from different sources which might have different time zones attached?

3. If you post the actual millisecond values for each, and your expected time zone, it should be pretty easy to determine which one of the two is off.