Расчётный период и обновление 005 > 007

[tail-n]

Здравствуйте! Помогите разабраться в проблеме при обновлениии.

Обновление производилось по http://www.netup.ru/UTM5/articles.php?n=48

ns usr # uname -a
Linux ns 2.6.31-gentoo-r6 #21 SMP Sat Nov 21 20:13:19 MSK 2009 AMD Phenom(tm) II X4 925 Processor AuthenticAMD GNU/Linux

Версия UTM5: UTM 5.2.1-007 Gentoo (RC2)

Проблема: сдвинулся расчётный период на 1 час назад.
Должно быть так: с 01.03.2010 00:00:00 по 01.04.2010 00:00:00

А получилось так: с 01.03.2010 00:00:00 по 31.03.2010 23:00:00

Спасибо, буду рад любым предложениям!

[Ata-man]

А если руками изменить дату окончания рассч. периода?

[tail-n]

Изменил, биллинг не отработал перевод на новый расчётный период.
Да к тому же это крайняя мера.

[mikkey finn]

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

[tail-n]

Это одному богу известно, вообщем мои действия таковы:

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

Посл: Тарификация - Расчётные периоды
Расчётный период изменился на 01.04.01:00, то есть сдвинулся уже на 1 час вперёд.

Мои действия, останавливая ядро, изменяю врем на серваке на 01.04 00:59, запускаю ядро, жду смены периода. Смотрю логи, а там интересный факт:

*ALERT : Jan 04 00:58:13 UTM5 Core: License check failed

[littlesavage]

Здравствуйте! Помогите разабраться в проблеме при обновлениии.
Спасибо, буду рад любым предложениям!

У вас, после ручного исправления, период случайно не сдвинулся опять на час вперед? Вместе со временем начала периода?

Есть подозрение, что просто админка неправильно переводит время из unix timestamp.
По московскому времени.
В начале месяца мы были в UTC+3 - начало и конец периода админка показывала с учетом UTC+3.
В конце месяца - мы в UTC+4. Начало и конец периода отображаются в нем.
А то что начало периода надо переводить по UTC+3, а конец - по UTC+4 не учитывается.

[Pulse]

олр

[dk]

Есть подозрение, что просто админка неправильно переводит время из unix timestamp.

Похоже что именно так.

Ничего не исправляли, в начале месяца расчётный период показывался до 23:00. Сейчас -- с 01.03 01:00 по 01.04 00:00. Да, уже после смены времени перезапускали биллинг из-за работ с электричеством, может и это важно.

[littlesavage]

Блин. Через пару часов после исправлений периода, каким-то образом появился еще один ежемесячный период длиною чуть меньше 1 дня, и в результате со всех снялась абон. плата 2 раза вместо одного :/

Больше не буду туда лезть

[tail-n]

Здравствуйте! Помогите разабраться в проблеме при обновлениии.
Спасибо, буду рад любым предложениям!

У вас, после ручного исправления, период случайно не сдвинулся опять на час вперед? Вместе со временем начала периода?

Есть подозрение, что просто админка неправильно переводит время из unix timestamp.
По московскому времени.
В начале месяца мы были в UTC+3 - начало и конец периода админка показывала с учетом UTC+3.
В конце месяца - мы в UTC+4. Начало и конец периода отображаются в нем.
А то что начало периода надо переводить по UTC+3, а конец - по UTC+4 не учитывается.

Да именно так и произошло, вообщем дождался перевода времени, но пока не тестировал. Вообще проблема решена была, там сначала появляется период до 23.00 но после достижения этого времени появляется новый расчётный период автоматически и уже с корректным временным интервалом.