![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Ох, какой ад
в Java c датой и временем.
Конкретно, чтобы на Clojure засунуть в jdbc параметр дату, пришлось перерыть весь гугл, исходники jaybird (firebird jdbc драйвера), внутренности joda-time и ее кложурной обертки clj-time
http://www.paullegato.com/blog/clojure-joda-sql-date-time/
(defn to-sql-date [date]
"Convert any Joda-readable date object (including a string) to a java.sql.Date"
(java.sql.Date. (.. (LocalDate. date) toDateMidnight toInstant getMillis)))
Основной затык - только в org.joda.time.LocalDate нормально сделана дата, без времени и временных зон. А jdbc драйвер понимает только java.sql.Date и вроде еще пару вариаций на тему "эпоха в long"
Конкретно, чтобы на Clojure засунуть в jdbc параметр дату, пришлось перерыть весь гугл, исходники jaybird (firebird jdbc драйвера), внутренности joda-time и ее кложурной обертки clj-time
http://www.paullegato.com/blog/clojure-joda-sql-date-time/
(defn to-sql-date [date]
"Convert any Joda-readable date object (including a string) to a java.sql.Date"
(java.sql.Date. (.. (LocalDate. date) toDateMidnight toInstant getMillis)))
Основной затык - только в org.joda.time.LocalDate нормально сделана дата, без времени и временных зон. А jdbc драйвер понимает только java.sql.Date и вроде еще пару вариаций на тему "эпоха в long"
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
ИМХО Если дата нужна "без времени и временных зон" - хранить её достаточно в стринге, и не заниматься никакой оккультной фигнёй.
no subject
no subject
Ну и библиотеки всякие есть, та же йода.
Ужасная задача в "чистой" джаве - посчитать сколько сегодня лет пациенту, зная "дату" его рождения :) Недавно наблюдал как два индуса и индуска засыпались, но справились, всего строк 300 кода :))
А так хочется чтобы был метод "getAgeByBirthDate"
no subject
no subject
Недавно работали с системой, в которой в очередной версии "проапгрейдили" внутренний тип данных Date (который был "тупой" набор трёх полей год-месяц-день с опциональной зоной) в "совместимый" с джавовским - который держит на самом деле время. Столько матерщизны собрали, если только время на клиенте не совпадает с временем на сервере - все клиенты рождаются вчера или завтра, все контракты подписаны "вчерашним днём", условленные даты в рамках контрактов попролетали на один день. Да что там другая зона, достаточно перейти на летнее/зимнее время и день перескакивает.
Не знаю как в оперденях, но обычный бизнес это разносит вдребезги.
Ад усугубляется тем, что куча всяких батчей тянет/пихает данные в другие системы как раз в районе полуночи, и разнос по датам - гарантирован. Особенно когда данные передаются XML, которые другая сторона парсит ещё добавляя и своё понимание к проблематике даты.
no subject
no subject
Говорят (индусы) у них в языках нет прошлого и будущего, вернее оно одним словом както говорится. Вобчем что вчера что завтра - всё одна маньяна
no subject
no subject
no subject
Соответственно в одних серверах хранится BCD-like просто дата, в других epoch локального (=серверного времени), в третьих можно с таймзоной, можно без, причём таймзона может быть а)серверная, б) аппсерверная в) браузерная г) из профиля пользователя. В odbc они говорят просто -- вот структура, сношайтесь как хотите. В jdbc есть некий аналог по умолчанию, но обычно вендоры дают и свои реализации.
Так что вся ваша жалоба из-за того, что вы хотите частный случай, который вендоры считают ненужным и неправильным.
no subject
no subject
Проблема даже глобальнее, она в том что для людей есть такое понятие как "дата" а для Джавы - нет. Тупо есть только время. То есть если контракт заключён в Минске с датой 1.1.2012 (на контракте так написано) и клиентское приложение в соответствии со всеми законами и правилами создало java.util.Date как полночь локального времени, итак для нормального человека это просто 1.1.2012, а для системы
это 31.12.2011 GMT + 3, и тут начинается ад, для клиентского приложения в Лондоне это 31.12.2011, для клиентского приложения в Москве это 1.1.2012. Что есть бред, даже если контракт заключён ночью у него одна "дата" - 1.1.2012.
Волевое решение писать все "даты" в одном временном поясе - например сервера помогает частично, танцы с переводам этой даты в человеческую дату клиента всё равно никто не отменял.
no subject
И с таймзоной и без таймзоны и отдельно дата без времени и отдельно время без даты.
no subject
no subject
И этим вашим Минским контрактам глубоко похер на таймзону. Не пишут в контракте в какой таймзоне он был заключен. Более того, можно сначала продать а потом в конце месяца задним числом подписать бумаги. И никого не колебет какая там была таймзона.
Ваш пример надуман.
no subject
no subject
no subject
no subject
no subject
Кроме того со стороны джавы проблема легко решается расширением типа даты.
no subject
no subject
no subject
no subject
no subject
no subject