Почему я не должен использовать date4j вместо joda java.util.Calendar или jsr 310?

Недавно я встретил date4j, чрезвычайно простая библиотека (по существу, один класс) для работы с датами в Java. Концептуально мне очень нравится "идея" date4j. Фактически, после прочтения всего основного сайта и документации в javadoc, я в значительной степени согласен со всем заявленным.

Теперь существует может несколько причин, почему я не должен использовать date4j - ошибки, производительность, отсутствие пользователей и т.д. Я не спрашиваю об этих вещах. Я спрашиваю, концептуально, что не так с идеей date4j (для большинства приложений там)? Конечно, могут быть некоторые приложения, которые нуждаются в чем-то вроде joda или threeten, но я считаю, что эти люди находятся в меньшинстве.

Обычный совет, который люди дают пользователям, связанным с датами/временем (почти все, кто пишет java-приложение), есть что-то вроде:

Используйте joda-time вместо java.util.Calendar
Установите ваш веб-сервер в UTC
Установите сервер базы данных в UTC
Сохраняйте дату в UTC

Фактически, последние три пулевых пункта иллюстрируют проблемы с текущей ментальной моделью, которую люди имеют при работе с датами. Люди пытаются управлять часовыми поясами как на уровне приложений, так и на уровне базы данных (не говоря уже о том, что рамки ORM добавляют еще один слой абстракции, что усложняет ситуацию).

Вам не нужно делать эти вещи. Например, если вы используете java.util.Calendar, и вы управляете временем в определенном пользовательском часовом поясе:

Calendar c = Calendar.getInstance(TimeZone.getTimeZone("America/New_York"));
c.set(Calendar.YEAR, 2011);
c.set(Calendar.MONTH, 0);
c.set(Calendar.DAY_OF_MONTH, 1);
c.set(Calendar.HOUR_OF_DAY, 3);
c.set(Calendar.MINUTE, 0);
c.set(Calendar.SECOND, 0);
c.set(Calendar.MILLISECOND, 0);

Это означает "мгновение" во времени, независимо от часового пояса. Вы должны быть в состоянии сохранять это время и из базы данных, не беспокоясь о каких-либо "конверсиях". Не имеет значения, находится ли база данных в часовом поясе в Шанхае, а веб-сервер находится в часовом поясе Лос-Анджелеса - время вовремя одинаковое.

Одна из проблем заключается в том, что некоторые базы данных пытаются управлять часовыми поясами для вас (я смотрю на вас, Postgres! grr!) и ухудшает поведение на уровне драйвера JDBC зависит от поставщика - то есть PreparedStatement.setDate/getDate.

Ментальная модель, используемая date4j, по-видимому, избавляет от всякой путаницы. Например, явно принудительно использует использование для предоставления часового пояса при вызове now(). На сайте есть очень хорошие рекомендации по использованию библиотеки (эти вещи я уже делал в своем собственном приложении ранее), например:

не использовать тип базы данных, который пытается управлять часовыми поясами
сохранить часовой пояс в виде отдельного столбца (если требуется)

Почему больше людей не принимают библиотеку, например date4j?

Ответ 1

Я до сих пор не смотрел date4j, но я прочитал документацию, и у меня есть одна конкретная проблема и одно мнение о том, что с ней не так.

Во-первых, конкретная проблема. Он не поддерживает часовой пояс внутри страны. Таким образом, существует двусмысленность в отношении летнего времени. Рассмотрим переход в воскресенье, когда 1:59:59 утра (EDT) становится 1:00:00 (EST). Ясно, что в тот день, говоря 1:30 утра, неоднозначно. Это время происходит дважды. Итак, следующее двусмысленно

new DateTime("2011-11-06 01:30:00")

Во-вторых, мое мнение. Проблема с Date заключалась в том, что она не поддерживала Timezone. К тому времени, когда пришел Календарь, урон был нанесен. Кроме того, сам календарь не сделал каких-либо выгод, будучи изменчивым. Но самое главное, решение должно включать не только момент, но и то, где оно было воспринято - часовой пояс, культура, язык. Затем их необходимо поддерживать рядом с моментом, когда он сохраняется в базе данных, сериализован, передан, что угодно. Этот же личный принцип позволяет мне смиренно предположить, что даже xsd: dateTime не подходит, потому что просто позволяет указывать дату + время относительно UTC, у нее нет положений, чтобы обеспечить, наблюдалось ли, например, летнее время.

Ответ 2

Это четыре года спустя, и я столкнулся с этим вопросом. Для меня проблема №1 с date4j - это ошибки. Я знаю, что вы конкретно не спрашивали об этом, но это серьезная проблема.

Более конкретно, сами ошибки сами по себе не являются проблемой, это полное отсутствие какой-либо системы отчетности об ошибках, которая беспокоит меня о date4j. Там даже нет списка рассылки, насколько мне известно, нет ничего. Я знаю, что это, вероятно, не очень интересно для обсуждения того, какой должен быть API-интерфейс даты/времени, но инфраструктура важна.

Недостаток одного вполне может быть причиной того, что библиотека не принимается широко.