m4a12345 Опубликовано 6 ноября, 2015 · Жалоба Кто-нибуть сталкивался с тем, что нужно перевести время в биллинге на час назад? Нельзя же просто поменять системное время на сервере? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 6 ноября, 2015 · Жалоба Наиболее щадящий метод: останавливаем ядро биллинга и БД, откатываем время. Выжидаем час, чтобы не возникло старых записей "из будущего", и запускаем все снова. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 7 ноября, 2015 · Жалоба Темы были и на форуме netup. Вкратце - обновление tz на сервере на текущую, перезагруза сервера не требует, ntp-синхронизация. А вот у клиентах-админках, там геморроя полно. Обновить java или поставить обновление tz для России, или установить tz в админке неправильную... Мне - хватило этого, ибо время в админке очень зависит и от tz компа и от явы... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 7 ноября, 2015 · Жалоба Наиболее щадящий метод: останавливаем ядро биллинга и БД, откатываем время. Выжидаем час, чтобы не возникло старых записей "из будущего", и запускаем все снова. Так можно же и в биосе то же самое сделать - перевести время на час, подождать час и готово? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
m4a12345 Опубликовано 7 ноября, 2015 · Жалоба В общем перевели на живую :) Отключили ядро, Перевели время, Включили ядро. По базе: все записи корректно пишет, ничего не сломалось. Единственное, по перерасчеты аб.платы, которые после перезагруки появились в "будущем", биллинг решил их аннулировать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 7 ноября, 2015 · Жалоба Так можно же и в биосе то же самое сделать - перевести время на час, подождать час и готово? А почему бы не держать в биосе UTC? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 9 ноября, 2015 · Жалоба Единственное, по перерасчеты аб.платы, которые после перезагруки появились в "будущем", биллинг решил их аннулировать. Вот как раз для предотвращения таких ситуаций, и последующих разбирательств в лапше "это правильное списание, это неправильное, это откатилось, а это нет" я и предлагал подождать час. Попадется какой-нибудь мозгоклюй, и начнет кровь сворачивать по "неверным списаниям" трехмесячной давности. Кстати, судя по вопросу, кое-кто прощелкал прошлогоднюю вспышку с изменениями таймзон? :) В этом году вроде ничего не меняли. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 9 ноября, 2015 · Жалоба на сервере используйте таймзону UTC, и покончите с этим геморроем. на на клентской админке делайте прямое указание таймзоны (можно даже не обновлять TZ, просто подобрать соответствующую вашей) типа такого: #!bin/sh TZ='Asia/Novosibirsk' /usr/lib/jvm/java-1.5.0-sun/bin/java -Xmx192m -jar UTM_Admin.jar Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 9 ноября, 2015 · Жалоба ' timestamp='1447050266' post=1197302]на сервере используйте таймзону UTC, и покончите с этим геморроем. В этом случае предвидится очень занимательный секас с веб-интерфейсом и платежными системами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 9 ноября, 2015 · Жалоба с веб-интерфейсом и платежными системами. никто не мешает вебу в переменных окружения передать какие угодно таймзоны, а вот про платежные системы не понял, что там должно ломаться? к вам просто прилетает платеж, а какое время там у платежной системы, никого особо не волнует, вы же платеж записываете по приходу согласно своей таймзоне, или нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 10 ноября, 2015 · Жалоба ' timestamp='1447070354' post=1197529] никто не мешает вебу в переменных окружения передать какие угодно таймзоны, а вот про платежные системы не понял, что там должно ломаться? Сразу вижу проблему с отчетами. Вместо того, чтобы рутиной отслеживания локального времени возлагать на систему, мы берем эту функцию на себя и будем это постоянно помнить, что на входе от пользователя время локальное, а к базе-ядру надо обращаться по UTC. ' timestamp='1447070354' post=1197529]к вам просто прилетает платеж, а какое время там у платежной системы, никого особо не волнует, вы же платеж записываете по приходу согласно своей таймзоне, или нет? У платежа два поля - дата платежа, сообщаемая платежной системой, и дата фактического зачисления, генерируемая ядром биллинга. В вашем случае вторая дата будет меньше, чем первая. И это тоже придется как-то учитывать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sqquirrel Опубликовано 10 ноября, 2015 · Жалоба Отключили ядро, Перевели время, Включили ядро. Мы ещё меняли таймзону в php и в mysql. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 10 ноября, 2015 · Жалоба И это тоже придется как-то учитывать. Запускать процесс импорта платежей тоже с нужной таймзоной? За все платежные системы не скажу, но время идет в формате unix timestamp (UTC), и, соответственно, подчиняется общим правилам отображения времени. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 10 ноября, 2015 · Жалоба Сразу вижу проблему с отчетами. Вместо того, чтобы рутиной отслеживания локального времени возлагать на систему, мы берем эту функцию на себя и будем это постоянно помнить, что на входе от пользователя время локальное, а к базе-ядру надо обращаться по UTC. Что-то совсем запутали. Все операционика идет в timestamp UTC - платежи, события и т.д. Отображение идет, как localtime, время-зависимые принятия решения тоже идет в отображаемом формате. Система сама разберется, где что лежит. Что отслеживать то надо? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...