Отображение статистики портов опроса GSM по часовым поясам

Тема возникла из Проблемы со статистикой портов опроса GSM - #7 от пользователя slavniy

Оказалось, что статистику портов опроса GSM вы показываете нестандартно: она привязывается к часовому поясу АРМ пользователя. А именно:

Вот замечания к этом:

    1. Такой подход уже вызвал у меня проблемы в общении с клиентом. При анализе статистики по опросам CSD возникает рассинхронизация данных. Два оператора в разных часовых поясах (например, Москва, Екатеринбург и Новосибирск), открыв одну и ту же вкладку статистики портов, увидят разные цифры за одни и те же «сутки». Поскольку расписание автоопроса настроено по времени сервера, корректно увидеть статистику может только пользователь, у которого часовой пояс АРМ совпадает с часовым поясом сервера. Это означает, что, возможно, ни один из трёх операторов может не увидеть корректные данные. :slight_smile:

Данный подход уже привел меня к проблемам в общении с клиентом. При анализе статистики по опросам CSD получаетс рассинхронизация данных. Два оператора в разных часовых поясах (например, Москва, Екатеринбурге и Новосибирск), открыв одну и ту же вкладку по статистике портов, увидят разные цифры за одни и те же «сутки». А т.к. расписание автоопроса реализцуктес по времни сервера, а статистику опросов, корреткно видит только тот, кто открывает статистикой портов опроса GSM с АРМ у котого часовй пояс соответсвыует серверу. Т.е. возможно вообще никто из 3 вышеуказанных пользоватя из Москва, Екатеринбурге и Новосибирск :slight_smile:

Вывод: корректно оценивать статистику портов опроса GSM в текущей реализации следует локально на сервере.

  1. У меня уже были случаи, когда статистика, получаемая в автоматической рассылке, не совпадала с тем, что я видел в АРМ. Подозреваю, что часть проблем связана именно с разной интерпретацией времени. Когда это происходило, я не фиксировал случаи документально, были более срочные задачи, поэтому подтверждений нет, но воспоминания остались.

  2. Иногда логи сеансов связи с явно указанной датой ПО интерпретируются как относящиеся к другой дате. Это заметно по вкладкам «вчера» и «сегодня» и выглядит как ошибка.

Предложение: текущий подход — показывать статистику с учётом часового пояса пользователя АРМ — неудобен и вводит в заблуждение. Продлагаю отображать статистику по времени сервера, одинаково для всех пользователей. Если пользователь анализирует параметры связи в распределённой системе, ему нужно понимать о часовых поясах и о местоположении модемов и сервера.

можно добавить галочку “Учитывать часовой пояс АРМ” выключенную по-умолчанию.

Ну это вполне логично и ожидаемо, у них сутки разные.

Вопрос очень спорный насчёт того, что пользователь должен помнить о часовых поясах серверов, модемов, служб опроса. Большинство систем предлагают анализировать такие данные именно по локальному времени, которое сейчас настроено у клиента. Мы, соответственно, опираемся на опыт уже существующих систем.

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

Текущая логика все равно отображения, на мой взгляд, времени требует доработки. На скриншоте показана эта проблема.

Поскольку данные в системе хранятся в формате UTC и вы все равно каждый раз при выводе на экран его изменяете, можно предоставить пользователю возможность самостоятельно выбирать часовой пояс для просмотра статистики. Возможные варианты отображения: UTC, время сервера, время пользователя или время конкретной территории (если объекты учета распределены по разным регионам).

Предлагаю реализовать два базовых варианта преднастроек (по времени сервера и по времени пользователя), а также добавить возможность вручную задавать смещение времени, добавив в начало списка варианты: время сервера, время пользователя (если оно равно времени сервера, то не указывать этот вариант) При этом необходимо явно указывать используемый часовой пояс на активной вкладке и обеспечить единообразие отображения времени во всех окнах в рамках текущего сеанса работы.

Вы уже сообщали об этой проблеме, она решена в 3.66.2.