Согласен, заголовок раздела отчета не соответствует данным, т.к. отображаются критические сообщения за период с dd - 1.MM.yyyy 00:00:00 по dd.MM.yyyy hh:mm:ss, где dd.MM.yyyy hh:mm:ss -это момент формирования отчета.
Достаточно ли будет простого изменения заголовка на ‘Критические сообщения за период с dd-1.MM.yyyy по dd.MM.yyyy hh:mm:ss’ и смены формата вывода для колонки ‘Время’ ?
Например, если отчет формируется 07.05.2024 в 09:11:53, то будут отображены критические сообщения за период с 06.05.2024 00:00:00 по 07.05.2024 09:11:53
В колонке ‘Время’ значения отображаются в UTC формате, поэтому для вашего часового пояса сдвиг на 5 часов.
При формировании отчета этот сдвиг можно учесть и привести значения к локальному времени сервера.
Но если сервер и клиент находятся в разных часовых поясах, то отображаемое время в системном журнале будет локальным временем клиента и оно не будет совпадать с отображаемым временем в отчете.
Как вариант решения, можно в узле ‘Параметры состояния системы->Критические события’ создать вычисляемое поле, например dateTimeToLocal, получать для него значение в скрипте:
private void dateTimeToLocal_GetValue(object sender, DevExpress.XtraReports.UI.GetValueEventArgs e)
{
e.Value = ((DateTime)e.GetColumnValue(“DateTime”)).ToLocalTime();
}
и использовать это поле в колонке ‘Время’ в подотчете DetailReportFatalErrors.
А почему не привести системный отчет в соответсвии в вашими требованиями. Ведь ваш совет
подойдет для обоих описанных вами вариантов: и когда сервер и клиент (скорее учетная запись) находятся в разных часовых поясах, и когда в одном часовом поясе
Я говорил о рассогласовании времени в системном журнале и отчете, когда сервер и клиент в разных часовых поясах, т.к. отчет формируется на сервере, а время для системного журнала формируется на клиенте.
Хорошо. Но в отчете у вас заложено рассогласование для всех случаев отчета, раз показываете в одой колонке время в UTC формате, а в соседней это уже время сервера.
Давайте хотя бы в колонке показывать время и дату по времени сервера.