Есть ли минусы в использовании Joda-Time?

Question

Я хочу убедить менеджера архитектуры включить банку Joda-Time в наш продукт.

Знаете ли вы какие-либо недостатки в его использовании?

Я думаю, что Joda-Time нужно постоянно обновлять из-за файлов, которые он включает. И это недостаток. Может быть, я ошибаюсь.

Не могли бы вы дать некоторую ясность по этому вопросу?

Answer 1

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

Тем не менее, по большей части это было приятно использовать - неизменность делает код намного проще для размышлений, а безопасность потоков для форматировщиков чрезвычайно полезна.

Да, есть файлы, которые нужно обновлять, но, по крайней мере, вы можете обновлять их. Не то, чтобы они содержали вещи, которые были ненужными со встроенными вещами Java, просто с помощью механизма Java вы просто не могли бы обновлять информацию, такую ​​как часовые пояса, без значительных взломов!

В основном +1 для использования Joda Time. API даты / времени Java является одним из худших элементов платформы Java, IMO.

Answer 2

На мой взгляд, самый важный недостаток Joda-Time связан с точностью: многие базы данных хранят метки времени с точностью микросекунда (или даже наносекунда ). Joda-время идет только до миллисекунд . Это неприемлемо для меня: все классы «модели данных», которые я использую, должны отражать полную точность данных в моей базе данных. Аппроксимации или усечения моих данных библиотекой просто не сокращают их.

Вот причина выбора миллисекундной точности, взятая из списка рассылки JSR 310 :

«Компания Joda-Time решила использовать миллисекунды, поскольку она упростила преобразование в дату и календарь». - С. Коулборн

Легче для кого? Автор библиотеки, можно предположить ... Неправильное проектное решение, на мой взгляд, когда почти все базы данных сохраняют время с точностью до микросекунды / наносекунды. Беспокойство по поводу значений базы данных вызывает беспокойство.

Answer 3

Самой большой проблемой, с которой мы столкнулись при использовании Joda Time, была интеграция со Spring и Tapestry, поскольку они оба хотели использовать встроенные дату и время. Мы постоянно писали обертки в методах получения / установки для даты и времени: либо мы сохраним это как Joda Time, и один набор получателей / установщиков передал его, а другой преобразовал бы на лету, а некоторые классы хранили его внутренне как Java Дата / Время, и установщик / установщик Joda должен был переключать его на лету.

По сути, это была головная боль, потому что классы названы одинаково, и если вы не сможете заставить всю свою архитектуру (включая другие библиотеки, которые вы интегрируете) переключаться на Joda Time, вы будете писать больше кода-обертки, чем вы. скорее всего сэкономит с помощью библиотек Joda.

Answer 4

хосты Parleys презентация Стивена Колебурна о JSR-310 , мистере Колобурне, авторе Joda-Time и JSR-310. Он начинает с объяснения слабых сторон стандартной поддержки даты / времени в Java и почему вы хотите использовать альтернативу. Может быть полезно показать эту презентацию вашему менеджеру архитектуры. Я не могу, кажется, глубокая ссылка

Причина, по которой Joda-Time обновляет свой файл часовых поясов довольно часто, заключается в том, что данные часовых поясов меняются все время, часто в короткие сроки (сегодня на слэш-точке: добавлена ​​секунда високосного 2008-12-31 ), а не всегда с научной точки зрения (например, я помню, что какое-то тихоокеанское островное государство изменило свой часовой пояс, чтобы стать первой страной, вступившей в 2000 год).

Answer 5

Выбор миллисекунд для основного временного континуума хорош для реализации календарей древности и специальных календарей. В отличие от многих счетчиков, 64-битный счетчик миллисекунд имеет хороший охват диапазона для календарей древности со свойствами переворачивания, превышающими +/- 260 миллионов лет.

Не обрабатывает високосные секунды. Это хорошая вещь. Люди с атомными часами предлагают плавный переход, чтобы позволить системам, которые не используют високосные секунды, постепенно регулировать свои часы в течение 100 секунд, чтобы учесть поправку на високосную секунду.

Обслуживание таблиц часовых поясов также будет проблемой.

Базовый континуум также позволяет использовать старый французский календарь и часы, которые делят день на 10 интервалов, называемых метрическим временем, вместо 24 часов. Классический китайский календарь делит день на 100 приращений, каждый продолжительностью чуть более 14 минут. Все эти календари могут быть реализованы и скоординированы в базовом континууме времени в миллисекундах.

Answer 6

В прошлом я сталкивался с компаниями, которые не хотели включать стороннее программное обеспечение с открытым исходным кодом или, по крайней мере, требовали, чтобы юрист компании подтвердил, что лицензия не будет подвергать их какой-либо ответственности или оказывают вирусное воздействие на свой продукт.

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

Answer 7

Основная проблема заключается в том, что поставщик заблокирован, по крайней мере, до тех пор, пока он не станет частью стандарта.

По большей части я бы использовал longs для хранения любой информации о бизнес-дате в базе данных. Это дает мне гибкость в настройке точности по своему усмотрению. В большинстве случаев я просто конвертирую их в java.util.Date.

Часовые пояса. Я бы отнесся к проблеме уровня представления, а не к данным. Это упрощает базу данных и повышает переносимость, поскольку базы данных могут представлять временные значения в разных формах.

Стандартный класс Calendar предоставляет мне некоторые функции манипуляции с датой, которые я преобразовываю в миллисекунды с момента начала периода.

Что касается наносекундной точности, я бы сохранил это как смещение от 0 как отдельный длинный столбец.