Неправильные даты и время в моих вопросах и графиках¶

Вы выполняете вычисления с датами и временем или отображаете их в графиках, но:

Значения кажутся неправильными, или
Суммарные значения неправильные.

Связана ли проблема с часовыми поясами?¶

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

Шаги для выполнения:

Для решения этой проблемы вам понадобятся ответы на следующие вопросы:

Какая временная зона для ваших данных отображается неправильно (т.е. какой должен быть правильный ответ)?
Есть ли явная настройка часового пояса на каждой временной метке, или некоторые или все временные метки хранятся без часового пояса? Например, Dec 1, 2019 00:00:00Z00 включает часовой пояс (показан после Z), но Dec 1, 2019 - нет.
Какой часовой пояс использует сервер базы данных?
Какой часовой пояс использует GlarusBI?

Как только вы получите ответы на эти вопросы, ищите случаи, подобные этим:

Ваш вопрос или график сравнивает, или сортирует значения с несогласованными или отсутствующими часовыми поясами. Например, если время вылета и прилета самолета сообщается в местном времени, то он может прибыть до того, как он вылетит.
Ваш вопрос агрегирует временные штампы с разными часовыми поясами: например, “ежедневные” итоги посещаемости вашего веб-сайта включают более 24 часов данных, потому что вы используете местные даты из Восточной Азии, Европы и Америки.

Как только вы поймете, что идентифицировали проблему - углубитесь в нее, чтобы понять, какая именно конвертация часового пояса вызывает ошибку. Например, предположим, что вы смотрите на временной ряд с ежедневными значениями; если ваша ошибка происходит с недельными итогами, вы можете сделать следующее:

Выберите конкретный день, в котором вы знаете, что число неправильное.
Нажмите на точку данных в графике или ячейку в таблице результатов и выберите “Просмотреть эти X”.
Откройте этот вопрос в двух других вкладках вашего браузера. Измените фильтры даты так, чтобы одна вкладка имела строки в базовой таблице из предыдущего дня, а другая таблица имела строки в базовой таблице из следующего дня.
Проверьте, что поле даты, используемое для группировки результата в базовом отображении, является правильным. Если он отличается от того, что у вас хранится в базе данных или в другом инструменте, то временная метка преобразуется неправильно. Это часто происходит, когда вы используете дату или время без явного часового пояса.
Если базовые временные метки правильны (что должно быть так, в случае, если они имеют явные часовые пояса), то отдельные времена, вероятно, группируются в дни в другом часовом поясе, отличном от того, который вам нужен
Чтобы узнать, в какой часовой пояс они преобразуются, измените времена на фильтрах даты в вопросе, который вы смотрите, перемещая начальное время и начальную дату назад на час, пока вы не получите правильное число, или вы не вернулись на 12 часов. (Если какой-либо из ваших часовых поясов включает Индию, Ньюфаундленд или другую юрисдикцию с часовым поясом полушага, вам может потребоваться сделать это с интервалом в полчаса.)
Если это не сработает, попробуйте переместить начальное и конечное время вперед на час, пока вы не получите правильное число, или вы не продвинулись на 12 часов вперед.
Если к этому моменту у вас есть правильное значение, это означает, что ваш часовой пояс был преобразован на количество часов вперед или назад, которое вы вручную установили фильтром. Если это так, проверьте, соответствует ли смещение, которое вы придумали, либо часовому поясу хранилища данных, либо часовому поясу самого GlarusBI.

Неправильно ли установлен часовой пояс отчета?¶

Исходная причина: Неправильные числа в вопросах или диаграммах могут быть вызваны несоответствием часового пояса, используемого GlarusBI, и часового пояса, используемого хранилищем данных.

Шаги для выполнения:

Проверьте Настройки временной зоны отчета из Настроек администратора > Настройки > Локализация.
Если вы используете базу данных, которая не поддерживает настройку часового пояса отчета, убедитесь, что часовой пояс GlarusBI соответствует часовому поясу базы данных. Часовой пояс GlarusBI - это часовой пояс виртуальной машины Java, обычно устанавливаемый с помощью параметра -Duser.timezone<..> или переменной среды JAVA_TIMEZONE; точно так же, как он устанавливается, будет зависеть от того, как вы запускаете GlarusBI. Обратите внимание, что часовой пояс GlarusBI не влияет на базы данных, которые используют часовой пояс отчета.

Запросы SQL не учитывают настройку часового пояса отчета?¶

Исходная причина: Мы в настоящее время не применяем часовой пояс отчета к результатам SQL-запросов.

Шаги для выполнения:

Установите часовой пояс отчета явно в своем SQL-запросе.

Например, вы можете написать что-то вроде этого с PostgreSQL:

SELECT column::TIMESTAMP AT TIME ZONE 'EST' AS column_est

Это выражение сначала приводит столбец к типу данных timestamp, а затем преобразует timestamp в тип данных timestamptz с часовым поясом «EST».

Даты без явного часового пояса преобразуются в другой день?¶

Исходная причина: Вы группируете по дате (а не по времени), которая не имеет часового пояса.

Шаги для выполнения:

Проверьте каждое использование полей вашего фильтра и убедитесь в том, что каждое из них имеет простой тип “Дата”
Если это так, убедитесь, что часовой пояс сервера соответствует часовому поясу отчета, потому что при выполнении запроса в GlarusBI сервер применяет настроенный часовой пояс к этой дате.

Вы смешиваете явные и неявные часовые пояса?¶

Исходная причина: Вы сравниваете или выполняете арифметические операции над двумя датами, где одна имеет явный часовой пояс, а другая - нет.

Шаги для выполнения:

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