I have a TreeMap of <DDate, Integer>
.
DDate just contains month and year (month is 0 indexed, like in Java, JAN = 0);
My compare is not returning the right thing:
@Override
public int compareTo(DDDate o) {
Calendar cal1 = Calendar.getInstance();
cal1.setTimeZone(TimeZone.getTimeZone("UTC"));
cal1.set(year, month, 1); // year is 2012, month is 1
Calendar cal2 = Calendar.getInstance();
cal2.setTimeZone(TimeZone.getTimeZone("UTC"));
cal2.set(o.getYear(), o.getMonth(), 1); // year is 2012, month is 1
Log.log("COMPARING: " + format.format(cal1.getTime())); // COMPARING: 20120101
Log.log("COMPARING: " + format.format(cal2.getTime())); // COMPARING: 20120101
Log.log((cal1.getTime().getTime())); // 1325413927678
Log.log((cal2.getTime().getTime())); // 1325413927679
Log.log("WILL RETURN: " + cal1.getTime().compareTo(cal2.getTime())); // WILL RETURN: -1
return cal1.getTime().compareTo(cal2.getTime());
}
Why is there descrepancy in the two Calendar objects for the same Date? (1325413927678 vs 1325413927679)
Thank you!
FYI: this method works for a while, and then at a certain point, stops working.
P.S. - I understand this is overkill, I can have a simpler compareTo, but please humor me.
EDIT- FIX
Use JodaTime's LocalDate.
Or do this:
Calendar cal1 = Calendar.getInstance();
cal1.setTimeZone(TimeZone.getTimeZone("UTC"));
cal1.clear();
cal1.set(year, month, 1); // year is 2012, month is 1
You're setting the year, month and day - but that doesn't change the time of day. The internal clock must have ticked between the two calls to Calendar.getInstance
, so they have different "milliseconds since the Unix epoch" values.
Personally I'd recommend using Joda Time instead of java.util.Calendar
and java.util.Date
- that way you can represent what you're actually interested in, such as LocalDate
.
See more on this question at Stackoverflow