Introduction

Yes, it is possible, but the cleanest approach depends on whether you are stuck with legacy date APIs or you can use java.time. A java.util.Date represents an instant in time, while GregorianCalendar and LocalDate are better tools when you need fields such as year, month, and day for comparison.

Extract Fields from Date with Calendar

If your code already uses java.util.Date, the classic way to get calendar fields is to load the Date into a Calendar or GregorianCalendar and then read the parts you need:

1import java.util.Calendar;
2import java.util.Date;
3import java.util.GregorianCalendar;
4
5Date date = new Date();
6GregorianCalendar calendar = new GregorianCalendar();
7calendar.setTime(date);
8
9int year = calendar.get(Calendar.YEAR);
10int month = calendar.get(Calendar.MONTH); // zero-based
11int day = calendar.get(Calendar.DAY_OF_MONTH);
12
13System.out.println(year + "-" + month + "-" + day);

This works, but there is an important detail: Calendar.MONTH is zero-based. January is 0, February is 1, and so on. That is easy to forget when you compare values or print them for debugging.

If you want to compare only the date portion, you can extract the fields from both values and compare them directly:

1GregorianCalendar expected = new GregorianCalendar(2025, Calendar.JANUARY, 27);
2
3boolean sameDate =
4    calendar.get(Calendar.YEAR) == expected.get(Calendar.YEAR) &&
5    calendar.get(Calendar.MONTH) == expected.get(Calendar.MONTH) &&
6    calendar.get(Calendar.DAY_OF_MONTH) == expected.get(Calendar.DAY_OF_MONTH);
7
8System.out.println(sameDate);

Prefer java.time for Newer Code

If you are on Java 8 or later, converting the legacy Date to LocalDate is usually easier to reason about. LocalDate represents a date without a time-of-day component, which makes day-level comparisons much clearer.

1import java.time.LocalDate;
2import java.time.ZoneId;
3import java.util.Date;
4
5Date date = new Date();
6
7LocalDate localDate = date.toInstant()
8    .atZone(ZoneId.systemDefault())
9    .toLocalDate();
10
11int year = localDate.getYear();
12int month = localDate.getMonthValue(); // one-based
13int day = localDate.getDayOfMonth();
14
15System.out.println(year + "-" + month + "-" + day);

Notice that LocalDate uses one-based month values, which is usually more intuitive than Calendar.

Compare Date and GregorianCalendar Safely

If the other value is already a GregorianCalendar, you can convert both sides into the same representation before comparing. A common approach is to turn both into LocalDate values:

1import java.time.LocalDate;
2import java.time.ZoneId;
3import java.util.Date;
4import java.util.GregorianCalendar;
5
6Date date = new Date();
7GregorianCalendar other = new GregorianCalendar(2025, GregorianCalendar.JANUARY, 27);
8
9LocalDate left = date.toInstant()
10    .atZone(ZoneId.systemDefault())
11    .toLocalDate();
12
13LocalDate right = other.toZonedDateTime().toLocalDate();
14
15System.out.println(left.equals(right));

This avoids manually comparing three or more separate fields and makes the intent obvious: you are comparing dates, not timestamps.

If you actually care about the exact instant, compare Instant values instead. That gives a very different answer from comparing only year, month, and day.

Know What You Are Comparing

This distinction matters a lot:

• 'Date includes time and milliseconds.'
• 'GregorianCalendar includes time and time zone.'
• 'LocalDate is date-only.'

If the question is "are these on the same calendar day", convert to LocalDate. If the question is "are these exactly the same moment", compare instants or milliseconds.

That separation prevents subtle bugs where two values look equal in logs but differ by hours because they came from different time zones.

Common Pitfalls

The biggest legacy pitfall is forgetting that Calendar.MONTH is zero-based. Many bugs come from treating March as 3 instead of 2 in Calendar.

Another common problem is comparing a Date directly to a GregorianCalendar without first converting them to a shared representation. The APIs model time differently, so direct comparisons can be confusing.

People also mix "same instant" and "same calendar date" as if they were the same check. They are not. A timestamp late at night in one zone may become the next day in another zone.

Finally, avoid the old deprecated getters on Date such as getYear() and getMonth(). They still exist for historical reasons, but Calendar or java.time is the safer approach.

Summary

• Yes, you can extract year, month, and day from Date, usually by first converting it to Calendar.
• 'Calendar.MONTH is zero-based, so handle month values carefully.'
• For new code, convert legacy Date objects to LocalDate when you need date-only comparison.
• Compare both values in the same representation before deciding whether they match.
• Choose between date-only comparison and exact-instant comparison deliberately, because they solve different problems.