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

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

25 голосов
/ 25 августа 2011

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

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

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

  • Используйте 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?

Ответы [ 2 ]

7 голосов
/ 25 августа 2011

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

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

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

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

1 голос
/ 01 июля 2015

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

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

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

...