我注意到TimeUnit类的一个奇怪的行为,所以我创建了这个最小的例子来重现它。
long differenceInDays;
Calendar c1 = Calendar.getInstance();
Calendar c2 = Calendar.getInstance();
c1.setTimeInMillis(1466062306000l); // Thu Jun 16 2016 09:31:46 GMT+0200
c2.setTimeInMillis(1466028000000l); // Thu Jun 16 2016 00:00:00 GMT+0200
differenceInDays = TimeUnit.DAYS.convert(c2.getTimeInMillis() - c1.getTimeInMillis(), TimeUnit.MILLISECONDS);
System.out.println(differenceInDays); // obviously zero
c2.add(Calendar.DATE, +1);
differenceInDays = TimeUnit.DAYS.convert(c2.getTimeInMillis() - c1.getTimeInMillis(), TimeUnit.MILLISECONDS);
System.out.println(differenceInDays); // why zero and not one?
c2.add(Calendar.DATE, +1);
differenceInDays = TimeUnit.DAYS.convert(c2.getTimeInMillis() - c1.getTimeInMillis(), TimeUnit.MILLISECONDS);
System.out.println(differenceInDays); // suddenly a 1, but not a 2 like expected
很明显,第一次计算差异时它是0,因为日期之间不是一整天。
但是第二次添加了一整天,那么差异如何仍然是0?
输出:
0 0
1
我不认为这个问题是夏令时或闰年相关,因为我只在同一年甚至一个月内进行计算。
Here是一个毫秒计算器,供您检查。
答案 0 :(得分:10)
通过简单的数学运算,您可以更好地了解这里发生了什么:
c1 = 1466062306000
c2 = 1466028000000
d = 86400000 // one day
c2 - c1 = -34306000 // negative, but less than one day in magnitude
c2 - c1 + d = 52094000 // less than one day
c2 - c1 + d + d = 138494000 // more than one day, less than two days
正确处理此问题的方法,假设您使用的是Java 8,如下所示:
// Decide what time zone you want to work in
ZoneId tz = ZoneId.of("Europe/Berlin");
// If you wanted the local time zone of the system,
// Use this instead:
// ZoneId tz = ZoneId.systemDefault();
// Get instants from the timestamps
Instant i1 = Instant.ofEpochMilli(1466062306000l);
Instant i2 = Instant.ofEpochMilli(1466028000000l);
// Get the calendar date in the specified time zone for each value
LocalDate d1 = i1.atZone(tz).toLocalDate();
LocalDate d2 = i2.atZone(tz).toLocalDate();
// Get the difference in days
long daysBetween = ChronoUnit.DAYS.between(d2, d1);
如果您的输入是真正的Calendar
个对象而不是时间戳,我建议Calendar.toInstant()
指导中提及{{1}}。
如果您使用的是Java 7或更早版本,您将从Legacy Date-Time Code库中找到类似的功能。
如果你真的不想使用其中的任何一种,并且仍然以旧的(硬)方式做事,那么请参阅Joda Time。