Перевод времени на час назад привел к сбою основного отчета. А именно в основном отчете не показывается абон. плата начисленная 01.10.2010. Также не правильно показываются входящие и исходящие остатки.
Версия UTM5: 5.2.1-007
ОС: Linux Debian 5
Проверял так: Если перевести дату на сервере на 11.10.2010 то все отображается правильно. Если перевести дату на 01.11.2010 то абон. плата с остатками показывается не правильно.
Как это вылечить?
Перевод времени. Сбой основного отчета
Присоединяюсь. UTM Admin некорректно воспринимает UNIXTIME из таблиц после перевода времени. Если смотреть простым SELECT'ом, то дата списания стоит 01.10.2010 00:07:00, но UTM Admin тем не менее уверен, что списание произошло 30.09.2010 в 23:07:00.
Если кто-то знает, как его переубедить - буду очень признателен.
Если кто-то знает, как его переубедить - буду очень признателен.
Да. Да. Именно так. Я, собственно, сам и не пользуюсь родными отчетами. У меня свои SQL запросы к базе. И мои отчеты работают вполне корректно. Они в сумме всегда совпадали с родным отчетом, а вот в октябре косячек вышел из-за перевода времени.UTM Admin некорректно воспринимает UNIXTIME из таблиц после перевода времени.
Я использую вот такую конструкцию для преобразования времени:
STR_TO_DATE(FROM_UNIXTIME(`discount_date`,'%Y-%m'),'%Y-%m')
Как-то странно получается, значит разработчики MySQL смогли написать нормальную функцию по конвертации UNIXTIME, а разработчики UTM5, видимо, нет?
А ларчик просто открывался. Собственно привожу ответ тех. поддержки.
Установил временную зону в Europe/Moscow и отчеты стали отображать правильные цифры.> Программное обеспечение: utm5
>
> Версия и номер сборки: 5.2.1-007
>
> Дата и время сборки:
>
> Полная версия дистрибутива операционной системы: Linux Debian 5
>
> Версия СУБД: Ver 5.0.51a-24+lenny4-log for debian-linux-gnu on i486 ((Debian))
>
> Дополнительные сведения о стороннем ПО:
>
> Краткое описание проблемы:
> Не корректное отображение начислений и остатков за октябрь в основном отчете.
> А именно абон. плата начисленная 01.10.2010 в 00:00. Данная проблема скорее
> всего связана с переводом времени на час назад в ночь с 30 на 31 октября.
> Проблема устраняется при изменении текущей даты например на 11.10.2010.
Подобная проблема известна и решена в версии 008. Она связана с
некорректным
определением временной зоны в интерфейсе администратора. В качестве
решения мы
рекомендуем при построении отчетов вручную устанавливать временную зону
в интерфейсе
администратора при построении данных за время до перевода часов.