[m4a12345]

Кто-нибуть сталкивался с тем, что нужно перевести время в биллинге на час назад? Нельзя же просто поменять системное время на сервере?

[taf_321]

Наиболее щадящий метод: останавливаем ядро биллинга и БД, откатываем время. Выжидаем час, чтобы не возникло старых записей "из будущего", и запускаем все снова.

[YuryD]

Темы были и на форуме netup. Вкратце - обновление tz на сервере на текущую, перезагруза сервера не требует, ntp-синхронизация. А вот у клиентах-админках, там геморроя полно. Обновить java или поставить обновление tz для России, или установить tz в админке неправильную... Мне - хватило этого, ибо время в админке очень зависит и от tz компа и от явы...

[Saab95]

Наиболее щадящий метод: останавливаем ядро биллинга и БД, откатываем время. Выжидаем час, чтобы не возникло старых записей "из будущего", и запускаем все снова.

 

Так можно же и в биосе то же самое сделать - перевести время на час, подождать час и готово?

[m4a12345]

В общем перевели на живую :)

Отключили ядро,

Перевели время,

Включили ядро.

По базе: все записи корректно пишет, ничего не сломалось.

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

[vop]

Так можно же и в биосе то же самое сделать - перевести время на час, подождать час и готово?

 

А почему бы не держать в биосе UTC?

[taf_321]

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

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

 

Кстати, судя по вопросу, кое-кто прощелкал прошлогоднюю вспышку с изменениями таймзон? :) В этом году вроде ничего не меняли.

[[anp/hsw]]

на сервере используйте таймзону UTC, и покончите с этим геморроем.

 

на на клентской админке делайте прямое указание таймзоны (можно даже не обновлять TZ, просто подобрать соответствующую вашей)

 

типа такого:

 

#!bin/sh

TZ='Asia/Novosibirsk' /usr/lib/jvm/java-1.5.0-sun/bin/java -Xmx192m -jar UTM_Admin.jar

[taf_321]

' timestamp='1447050266' post=1197302]

на сервере используйте таймзону UTC, и покончите с этим геморроем.

 

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

[[anp/hsw]]

с веб-интерфейсом и платежными системами.

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

к вам просто прилетает платеж, а какое время там у платежной системы, никого особо не волнует, вы же платеж записываете по приходу согласно своей таймзоне, или нет?

[taf_321]

' timestamp='1447070354' post=1197529]

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

 

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

 

' timestamp='1447070354' post=1197529]

к вам просто прилетает платеж, а какое время там у платежной системы, никого особо не волнует, вы же платеж записываете по приходу согласно своей таймзоне, или нет?

 

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

[Sqquirrel]

Отключили ядро,

Перевели время,

Включили ядро.

 

Мы ещё меняли таймзону в php и в mysql.

[[anp/hsw]]

И это тоже придется как-то учитывать.

Запускать процесс импорта платежей тоже с нужной таймзоной?

За все платежные системы не скажу, но время идет в формате unix timestamp (UTC), и, соответственно, подчиняется общим правилам отображения времени.

[vop]

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

 

Что-то совсем запутали. Все операционика идет в timestamp UTC - платежи, события и т.д. Отображение идет, как localtime, время-зависимые принятия решения тоже идет в отображаемом формате. Система сама разберется, где что лежит. Что отслеживать то надо?