Comparing two Calendar objects

Question

I want to compare two Calendar objects to see if they both contain the same date. I don't care about any value below days.

I've implemented this and I can't think about any case where it should fail:

private static boolean areEqualDays(Calendar c1, Calendar c2) {
    SimpleDateFormat sdf = new SimpleDateFormat("dd-MM-yyyy");
    return (sdf.format(c1.getTime()).equals(sdf.format(c2.getTime())));
}

Is this approach correct or should I compare c1 and c2 field by field?

Advertisement

regarding "comparing c1 and c2" #1505996 – Nolita

It's a different thing. I'm asking about if it's a correct approach or if it has flaws I don't know about. Not the same as asking how to do it. – Advertisement

FYI, the terribly flawed date-time classes such as java.util.Date, java.util.Calendar, and java.text.SimpleDateFormat are now legacy, supplanted by the java.time classes built into Java 8 and later. – Chivers

Answer 1

I've implemented this and I can't think about any case where it should fail

It will fail if the two calendars are in different time zones - they could represent the exact same millisecond, but that instant could fall into different days based on the time zone.

It will also arguably fail if the two calendars represent different calendar systems - even if they represent the same "day", if the two calendars would represent that day differently, you could argue that it should fail.

Personally, I would strongly advise you to use Joda Time which has a LocalDate type to represent just a date - that would get rid of the time zone issue, but not the calendar system issue. If you can always assume that you're using the same calendar system, then that's okay.

(Additionally, performing string operations just for comparison purposes is ugly - I'd just check calendar.get(Calendar.YEAR) etc directly.)

Businesslike

Both of them are generated in the app, it won't fail unless you're crossing a time zone when using it, and since the app targets only Spain I'm not really concerned about that issue. – Advertisement

@santirivera92: "Generated in the app" doesn't mean "generated with the same time zone" necessarily - even though it sounds like the latter is the case. I would personally at least put comments around that... it's the kind of thing which is easily missed when requirements change. – Businesslike

Answer 2

Try compareTo

Calendar c1 = Calendar.getInstance();
Calendar c2 = Calendar.getInstance();
c1.compareTo(c2);

Returns:

the value 0 if the time represented by the argument is equal to the time represented by this Calendar; a value less than 0 if the time of this Calendar is before the time represented by the argument; and a value greater than 0 if the time of this Calendar is after the time represented by the argument.

EDIT

import org.apache.commons.lang3.time.DateUtils;

You can use DateUtils.isSameDay to check if it's the same day.

boolean isSameDay = DateUtils.isSameDay(c1, c2);

28 Mar 2002 13:45 and 28 Mar 2002 06:01 would return true. 28 Mar 2002 13:45 and 12 Mar 2002 13:45 would return false.

Ist

That will say that 10am today is unequal to 11am today - unlike the OP's method. The OP is only interested in the date. – Businesslike

Answer 3

You can use somehing like DateUtils

public boolean isSameDay(Calendar cal1, Calendar cal2) {
    if (cal1 == null || cal2 == null)
        return false;
    return (cal1.get(Calendar.ERA) == cal2.get(Calendar.ERA)
            && cal1.get(Calendar.YEAR) == cal2.get(Calendar.YEAR) 
            && cal1.get(Calendar.DAY_OF_YEAR) == cal2.get(Calendar.DAY_OF_YEAR));
}

You can also check if is the same date-time:

public boolean isSameDateTime(Calendar cal1, Calendar cal2) {
    // compare if is the same ERA, YEAR, DAY, HOUR, MINUTE and SECOND
    return (cal1.get(Calendar.ERA) == cal2.get(Calendar.ERA)
           && cal1.get(Calendar.YEAR) == cal2.get(Calendar.YEAR)
           && cal1.get(Calendar.DAY_OF_YEAR) == cal2.get(Calendar.DAY_OF_YEAR)
           && cal1.get(Calendar.HOUR_OF_DAY) == cal2.get(Calendar.HOUR_OF_DAY)
           && cal1.get(Calendar.MINUTE) == cal2.get(Calendar.MINUTE)
           && cal1.get(Calendar.SECOND) == cal2.get(Calendar.SECOND));
}

Vulcanology

Answer 4

tl;dr

( ( GregorianCalendar ) c1 )
.toZonedDateTime()
.toLocalDate()
.isEqual( 
    ( ( GregorianCalendar ) c2 )
    .toZonedDateTime()
    .toLocalDate()
)

java.time

The Answer by Jon Skeet is correct. But its suggestion to use Joda-Time is outmoded.

The date-time classes bundled with the earliest versions of Java were simply terrible. For example, Date & Calendar and its usual concrete class GregorianCalendar. The adoption of JSR 310 years supplanted those classes with the modern java.time classes. JSR 310 was led by the man who invented Joda-Time, Stephen Colebourne.

Calendar ➙ GregorianCalendar ➙ ZonedDateTime ➙ LocalDate

If given a Calendar convert to ZonedDateTime via GregorianCalendar.

if( myCal instanceOf GregorianCalendar ) {
    GregorianCalendar gc = ( GregorianCalendar ) myCal ; 
}

Then convert to its replacement, ZonedDateTime.

ZonedDateTime zdt = gc.toZonedDateTime() ;

Both GregorianCalendar & ZonedDateTime represent a moment, a specific point on the timeline. That moment viewed through two different time zones such as Tokyo Japan versus Toledo Ohio US could land on two different dates.

To represent a date-only, without time-of-day, and without time zone or offset-from-UTC, use LocalDate class.

LocalDate ld = zdt.toLocalDate() ;

You can compare a pair of LocalDate objects.

boolean isBefore = localDateX.isEqual( localDateY ) ;

You may want to adjust both ZonedDateTime objects to the same time zone before considering their date.

ZoneId zNewYork = ZoneId.of( "America/New_York" ) ;
ZonedDateTime zdtXNewYork = zdtX.withZoneSameInstant( zNewYork ) ;
LocalDate localDateX = zdtXNewYork.toLocalDate() ;

---

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.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - 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
  • Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  • Later versions of Android bundle implementations of the java.time classes.
  • For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). 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.

Chivers

Answer 5

Calendar class has got a method compareTo. Why don't you directly call that?

Thebault

Answer 6

To compare two dates with respect to a specific field, first set all fields below that one to the lowest value (which is 0 or 1 depending on the field) using Calendar.set(int field, int value) and then compare. To compare differing in days between cal1 and cal2, you will set MINUTE, SECOND and MILLISECOND on both objects to 0 before calling cal1.compare(cal2).

Langille