Почему мне не использовать 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?