Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5]      все
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Zzz79
mayton


Разумеется приложение должно фиксировать дату с учотом поясов чтобы правильно
сделать comparison.

зачем?
Эта дата используется лишь для распечатки документов на кредит)
типо дата подписи или что то в этом роде)
тоесть если клиент запросил кредит во владике -зачем мне в базу писать гринвич+ зона =чтобы потом обратно все жто дело преобразовывать,вместо того,чтобы записать время фактическое?

Не совсем правильный вопрос зачем.

Вопрос как правильно. Если твоя задача работает в системе без учота часовых поясов - то ты выбираешь ТИПЫ
данных для БД и JDBC которые не хранят часовой пояс.

Если твоя задача работает в нескольких часовых поясах и для нее важно ФИКСИРОВАТЬ время события
(чтобы в будущем принимать решения о причинно-следственной связи между событиями) то надо соотв.
брать SQL/JDBC типы с зоной. Зональны типы можно конвертить и форматировать красиво чтоб публиковать
+1,+2,+3 e.t.c.

Есть еще третий (гибридный вариант). Твоя систма фиксирует время зонированное но в базе или в системе
время сводится к времени UTC. Так мы делаем. С UTC проще делать арифметику т.к. это просто целое число.

Правда мы теряем сведения о зоне. Но нам пофиг. Если время например паблишится по Нью-Йорку всегда
независимо от того из какой зоны пришло событие.
14 апр 20, 11:13    [22115846]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
mayton,
как правильно поступить если клиента оформляли в москве
в 11.40 ( джейсон 11.40бла бла бла + 3.00)
в базе тип тайм стемп виз тайм зоне
записывается 8.40

и вот я хочу чтобы другой сервис ,который например находится во владике при распечатке документов выводил время обращение клиента 11.40

я так понимаю мы должны убрать тайм зону из базы,либо добавлять в маперы сервиса потребителя методы конвертации
14 апр 20, 11:18    [22115848]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Zzz79

и вот я хочу чтобы другой сервис ,который например находится во владике при распечатке документов выводил время обращение клиента 11.40

Я не могу рассказать это тебе оперируя гуманитарным текстом. Очевидно что надо что-то во что-то конвертить.

Я уже жду исходников и DDL таблицы.
14 апр 20, 11:21    [22115851]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4832
Zzz79,

Это спринг на тебя так влияет? Или облака?)
14 апр 20, 11:36    [22115859]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Alex_Ustinov
Member

Откуда: Nickel
Сообщений: 3220
Zzz79
мы должны убрать тайм зону из базы
базу держи в одной нулевой зоне, на клиенте конвертируй
14 апр 20, 12:13    [22115893]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
Alex_Ustinov
Zzz79
мы должны убрать тайм зону из базы
базу держи в одной нулевой зоне, на клиенте конвертируй

да у нас так и реализовано-я просто не пойму зачем туда сюда конвертировать дату эту?
ведь потребителю важно локальное время подписанта - поэтому получается я сначала дату кладу с тайм зоной потом обратно эту дату переконвертирую
14 апр 20, 12:45    [22115908]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Zzz79
Alex_Ustinov
пропущено...
базу держи в одной нулевой зоне, на клиенте конвертируй

да у нас так и реализовано-я просто не пойму зачем туда сюда конвертировать дату эту?
ведь потребителю важно локальное время подписанта - поэтому получается я сначала дату кладу с тайм зоной потом обратно эту дату переконвертирую

Что важно потребителю - это business requirements ТВОЕГО приложения. И мы их не знаем ясен пень.
В некоторых системах трекается два времени. Время фиксации события в системе. И время юридическое.
Например договор был составлен вчерашним числом но заведен в систему сегодня. Две даты.
14 апр 20, 12:50    [22115912]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Zzz79
Member

Откуда:
Сообщений: 168
mayton
Zzz79
пропущено...

да у нас так и реализовано-я просто не пойму зачем туда сюда конвертировать дату эту?
ведь потребителю важно локальное время подписанта - поэтому получается я сначала дату кладу с тайм зоной потом обратно эту дату переконвертирую

Что важно потребителю - это business requirements ТВОЕГО приложения. И мы их не знаем ясен пень.
В некоторых системах трекается два времени. Время фиксации события в системе. И время юридическое.
Например договор был составлен вчерашним числом но заведен в систему сегодня. Две даты.

для нас важно время по месту подписания договора
далее именно это время должны хавать все потребители( независимо от того места где они находятся )
тоесть ты пришел во владике взял кредит- поставил подпись в 11 00 ,значит это время должно вылезти и в мск при распечатке доков
поэтому я не пойму сакрального смысла конвертить 11 .00 сначала в 3.00 ,а заем обратно)
14 апр 20, 13:08    [22115927]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Я могу ответить на вопрос - "как сделать чтобы".

Но я не отвечу тебе на вопрос "почему". Это - к твоим архитекторам и бизнесам.
14 апр 20, 13:10    [22115932]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Garrick
Member

Откуда: Москва
Сообщений: 2999
Zzz79

Эта дата используется лишь для распечатки документов на кредит)
типо дата подписи или что то в этом роде)

О! Это вообще тема. Задачка для первого класса:
Условие:
Клиент 10-го числа в 7 утра во Владивостоке подписал кредитный договор. В Москве в это время ещё 9-е число. В конце месяца по кредиту начисляются проценты и, как правило, это делается в центральном офисе в Москве.
Вопрос:
За какое количество дней будут начислены проценты?
14 апр 20, 13:11    [22115933]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
mayton
Member

Откуда: loopback
Сообщений: 46531
Я-же говорю. Comparison двух дат. Или вот еще вариант - календарная арифметика интервалов.
14 апр 20, 13:13    [22115935]     Ответить | Цитировать Сообщить модератору
 Re: MySQL очень медленный  [new]
Alex_Ustinov
Member

Откуда: Nickel
Сообщений: 3220
Zzz79
то есть ты пришел во владике взял кредит- поставил подпись в 11 00 ,значит это время должно вылезти и в мск при распечатке доков
поэтому я не пойму сакрального смысла конвертить 11 .00 сначала в 3.00 ,а заем обратно)
ничего непонятно... но вроде все об одном. В доке должно стоять 11:00 (GMT+10) г.Владивосток (т.е. в базе будет 01-00). А то он прилетит в МСК и возьмет еще один кредит в 9-00 по МСК, ведь в МСК еще не будет 11-00..))
Так работают все сайты.....
14 апр 20, 17:48    [22116134]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5]      все
Все форумы / Java Ответить