Проблемы при расчете разницы между днями
Все объекты гарантированно имеют метод .equals(), поскольку Object содержит метод, .equals(), который возвращает логическое значение. Задача подкласса переопределять этот метод, если требуется дополнительное определение определения. Без него (т. Е. С помощью ==) только адреса памяти проверяются между двумя объектами для равенства. String переопределяет этот метод .equals() и вместо использования адреса памяти возвращает сравнение строк на уровне символа для равенства.
Ключевое замечание состоит в том, что строки хранятся в одном пуле, поэтому после создания строки он всегда хранится в программе по тому же адресу. Строки не меняются, они неизменяемы. Вот почему это плохая идея использовать регулярную конкатенацию строк, если у вас есть серьезное количество обработки строк. Вместо этого вы будете использовать предоставленные классы StringBuilder. Помните, что указатели на эту строку могут измениться, и если вам было интересно увидеть, были ли два указателя одинаковыми ==, это был бы прекрасный способ. Строки сами не делают.
3 ответа
Массив различий можно вычислить с помощью ChronoUnit. Вы также можете использовать поток для дальнейшего упрощения вашей реализации:
private static int[] abstandTage(GregorianCalendar date1,
ArrayList<GregorianCalendar> csvDate) {
return csvDate.stream()
.mapToInt(csvdate -> (int)
ChronoUnit.DAYS.between(date1.toZonedDateTime(), csvdate.toZonedDateTime()))
.toArray();
}
Как уже упоминалось выше, вам нужно будет использовать LocalDate здесь:
SimpleDateformat sdf = new SimpleDateFormat("yyyyMMdd");
Date date1 = sdf.parse("20180713);
Date date2 = sdf.parse("20180930");
LocalDate startDate =
date1.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
LocalDate endDate =
date2.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
long days = ChronoUnit.DAYS.between(startDate, endDate);
return days;
Преобразование из григорианского в Date выполняется через:
Date newDate = new Date(date1.getTime());
-
1Спасибо, что хотел внести свой вклад. Да, чтобы
LocalDate´, but when you can useLocalDate` изjava.time, не видит никакой причины использовать старомодныйDateили печально известныйSimpleDateFormat. Используйтеjava.timeисключительно. Это также проще. – Ole V.V. 13 July 2018 в 16:58 -
2Как Оле В.В. прокомментированные, ужасно трудные старые классы времени, такие как
java.util.Dateиjava.text.SimpleDateFormat, теперь legacy , вытесненные java.time классы, встроенные в Java 8 и более поздние версии. См. Учебное пособие от Oracle . Не смешивать устаревшие классы были полностью вытеснены java.time , поэтому не нужно смешивать. – Basil Bourque 14 July 2018 в 04:29
Это происходит, если вы создаете свои объекты GregorianCalendar, например, как new GregorianCalendar(2018, 7, 13) для 13 июля. GregorianCalendar использует нумерующий странный месяц, поэтому вы не получаете 13 июля.
Решение бросить этот длинный устаревший и плохо разработанный класс и создать свои даты, используя, например, LocalDate.of(2018, 7, 13) или даже лучше, LocalDate.of(2018, Month.JULY, 13). Затем используйте ChronoUnit.DAYS.between для нахождения количества дней между датами.
Ссылка: Учебник Oracle: Date Time , объясняющий, как использовать java.time, современную дату и время Java API.
-
1Благодаря вашему комментарию (странная нумерация) я нашел решение. Тем не менее, я собираюсь попробовать, как вы предлагали здесь, с Chronounit. Спасибо за ваши старания! Действительно оценен. – dribble290 13 July 2018 в 11:51
-
2@ dribble290 Старые устаревшие классы времени на самом деле - чертовски ужасный беспорядок. Sun, Oracle и JCP согласились заменить их на java.time по какой-то причине. На самом деле, для многих причин. Вы не пожалеете о принятии java.time . – Basil Bourque 14 July 2018 в 04:34
GregorianCalendar, это путь. Еще лучше, если вызывающий абонент пройдетLocalDateили другой современный класс даты и времени. – Ole V.V. 13 July 2018 в 11:03