Я собираюсь укусить: этот код - полная чушь. Если использование setGregorianChange()
имеет какую-либо цель (в чем я сомневаюсь), то это умный взлом, который не имеет никакого отношения к реальному коду. Но я сильно подозреваю, что тот, кто написал эту неприятную историю, просто не очень хорошо знал API Date / Calendar и действительно намеревался использовать Calendar.setTime () .
Дело против прямого сравнения Date
экземпляров в assertEquals()
, похоже, заключается в том, что внутренние временные метки экземпляров могут отличаться на миллисекунды, даже если они создаются сразу после другого - таким образом вводится «нечеткое сравнение» в форме Math.abs(differenceInMS) <= 1
. Но это также не требует обхода через GregorianCalendar
, и при этом не достаточно размытия - полный сборщик мусора или даже просто детализация часов могут легко привести к двум датам, созданным сразу после того, как другая будет на расстоянии 10 или более мс друг от друга.
Настоящая проблема заключается в отсутствии типа данных «календарная дата» в Java, что делает сравнение с гранулярностью дня довольно многословным (вы должны использовать Calendar
, чтобы установить для всех полей времени значение 0). Класс Joda Time DateMidnight - это то, что действительно нужно здесь.