Другие ответы, приведенные здесь, пока обрабатывают только дневную единицу как фиксированное количество в 24 часа, используя класс java.time.Duration.Если вы рассматриваете свои временные метки в контексте переключения часовых поясов на летнее время, то это, вероятно, не то, что вам нужно.
При переходе с зимнего на летнее время календарный день может длиться всего 23 часа (или даже 23 часа).: 30 в некоторых редких случаях).А осенью при переходе на зимнее время календарные дни могут длиться более 24 часов.Так что вам также нужен часовой пояс , чтобы справиться с этой ситуацией, чтобы правильно рассчитать длительности.
Предлагаемое решение, если ваши временные метки были сохранены в базе данных, полученной в моменты времени.:
ZonedDateTime zdt1 = date1.toInstant().atZone(ZoneId.systemDefault());
ZonedDateTime zdt2 = date2.toInstant().atZone(ZoneId.systemDefault());
long days = java.time.temporal.ChronoUnit.DAYS.between(zdt1, zdt2);
Конечно, вы можете указать любую другую зону, кроме системного часового пояса.Результат может варьироваться в зависимости от выбранной зоны.
Предлагаемое решение, если ваши временные метки были сохранены, исходя из LocalDateTime без какого-либо контекста зоны:
LocalDateTime ldt1 = date1.toLocalDateTime();
LocalDateTime ldt2 = date2.toLocalDateTime();
long days = java.time.temporal.ChronoUnit.DAYS.between(ldt1, ldt2);
ЗдесьЯ по-прежнему предпочитаю enum ChronoUnit.DAYS, потому что тип java.time.Duration хранит только секунды и наносекунды и поэтому скорее предназначен для временных меток, похожих на машины.И еще одно замечание: второе решение неявно использует часовой пояс вашей системы для преобразования из java.sql.Timestamp в LocalDateTime.Это верно только в том случае, если вы также сохранили свои метки времени таким образом.
Кстати, с драйвером, совместимым с JDBC-4.2 , вы также можете получить ваш java.timeвведите , см. также пост, связанный с здесь, на SO .