Сказать, что ваши две даты имеют разный формат, не совсем точно. У Date
нет формата. То, что вы видите, что вы печатаете даты, это возвращаемые значения их toString
методов.
Скорее, ваши даты имеют разные типы времени выполнения . d1
является экземпляром java.util.Date
, а его метод toString
создает формат Sat May 25 10:00:00 WET 2019
. d2
в свою очередь является экземпляром java.sql.Date
. Это подкласс java.util.Date
, поэтому его можно назначить переменной этого типа. java.sql.Date.toString()
создает формат 2019-05-25
. Однако отношения подкласса (наследования) - это хак, на который не следует полагаться в коде.
Хак наследования - лишь одна из многих проблем проектирования с этими двумя классами. К счастью, существует более новая и современная замена для обоих. Для java.util.Date
современный Instant
класс является наиболее соответствующим типом, но какой именно использовать, зависит от ваших более точных требований. Для java.sql.Date
это проще, используйте LocalDate
. И Instant
, и LocalDate
являются частью java.time, современного Java-API даты и времени.
Посмотрите, можете ли вы заменить bean.fooDate
на Instant
или другой подходящий современный тип из java.time. Точно так же посмотрите, можете ли вы получить fooEntity.getFooDate()
, чтобы вернуть LocalDate
. Hibernate должен быть рад обрабатывать для вас LocalDate
, а не Date
(если ваша версия Hibernate не очень старая).
В любом случае, Srinivasan Sekar является правильным, что вы должны конвертировать любой тип, который вы получаете от каждого, в LocalDate
, чтобы сравнивать только даты, а не часы, минуты и секунды. LocalDate
именно так: дата без времени суток.
Скажите, что вы получаете Instant
от bean.fooDate
. Тогда преобразование:
LocalDate localDate1 = bean.fooDate.atZone(ZoneId.of("Africa/El_Aaiun")).toLocalDate();
Обязательно укажите подходящий часовой пояс.
Если вы не можете избежать старомодного Date
, обращение в ответе Шринивасана Секара будет правильным:
LocalDate localDate1 = bean.fooDate
.toInstant()
.atZone(ZoneId.of("Africa/El_Aaiun"))
.toLocalDate();
В случае fooEntity.getFooDate()
, если вы можете получить LocalDate
, как уже упоминалось, все готово. Если вы можете получить только Date
, сначала проверьте, объявлен ли метод для возврата java.util.Date
или java.sql.Date
. Вероятно, это зависит от импорта, используемого в файле, где объявлен метод. Случай java.sql.Date
достаточно прост (хотя, к сожалению, не всегда даётся правильная дата):
LocalDate localDate2 = fooEntity.getFooDate().toLocalDate();
Если объявленный тип возврата равен java.util.Date
, вы можете просто добавить приведение к вышеприведенному, так как кажется, что фактически возвращаемый объект - java.sql.Date
. Сначала было бы безопаснее проверить ваше предположение:
LocalDate localDate2;
Date d2 = fooEntity.getFooDate();
if (d2 instanceof java.sql.Date) {
localDate2 = ((java.sql.Date) fooEntity.getFooDate()).toLocalDate();
} else {
localDate2 = d2.toInstant()
.atZone(ZoneId.of("Africa/El_Aaiun"))
.toLocalDate();
}
Вы поймете, что во втором случае я использую то же преобразование, что и выше.
Для сравнения результирующих LocalDate
переменных:
if (localDate1.isEqual(localDate2)) {
System.out.println("Same date");
} else {
System.out.println("Different dates");
}
LocalDate
также имеет методы isBefore
и isAfter
на тот случай, если вам нужно определить, что раньше.
Ссылка: Обучающее руководство по Oracle: Дата и время , объясняющее, как использовать java.time.