Даты и таймзоны

Формат на входе#

Даты передаются строкой YYYY-MM-DD. Времени в параметрах нет нигде: период всегда задаётся целыми сутками.

?start_date=2026-07-01&end_date=2026-07-31

Нераспознанная строка даёт 422 validation_error с указанием поля в details.

В какой зоне считаются сутки#

В зоне торгового центра. Для московского ТЦ end_date=2026-07-31 означает 31 июля 23:59:59 по Москве, а не по UTC. Иначе из выгрузки выпадали бы чеки, пробитые с полуночи до трёх ночи.

Зона каждого ТЦ приходит:

• в поле time_zone объекта в списке торговых центров;
• в meta.time_zone тех методов, где есть meta.

Ориентироваться стоит на неё, а не на зону сервера интеграции.

Формат на выходе#

Смещение присутствует всегда. Это осознанное отличие от v1, который отдавал время без зоны и заставлял догадываться.

Особенности отдельных методов#

Продажи по месяцам расширяют период до целых месяцев: запрос с 2026-05-10 по 2026-06-20 вернёт май и июнь целиком. Тарифное ограничение при этом проверяется по исходным датам, а не по расширенным.

Чеки фильтруются двумя независимыми парами дат: по времени пробития чека и по времени поступления к нам. Подробности в описании метода.

Почасовая посещаемость отдаёт местный час торгового центра: полдень в ответе это полдень в ТЦ.

Ограничения периода#

Длина окна ограничена тарифом торгового центра, а не датой начала: забрать данные трёхлетней давности можно, но частями.

Сверх этого у двух методов есть собственные фиксированные окна, которые PRO не снимает: у почасовой посещаемости 31 день, у чеков 31 день на каждую пару дат. Подробнее в разделе Тарифы.