- Зачем:
- спека разрослась до 1058 строк, а журнал решений в разделе 9 читался
только целиком; агентам и людям нужен дешевый адресный заход к
основаниям решений генератора.
- Что:
- заведены ADR 0015 (пояс счетчика), 0016 (паспорт куки) и 0017 (номер
заказа); четыре адресные ссылки на «раздел 9» перешиты на них.
- раздел 9 пересобран в 11 тематических подразделов с датами и тикетами
у каждого решения и закрыт пометкой о заморозке; устаревшие
промежуточные замеры свернуты до указателей на актуальные.
- строка статуса в шапке отмечает закрытие спеки как документа этапа 2.
- Проверка:
- wc -l docs/specs/2026-08-01-generator.md (951, было 1058);
rg -n 'раздел[а-яё]* 9|разделы 8 и 9' docs -g '*.md' — 18 попаданий,
все классифицированы; разделы 1-8 нетронуты (сверка хешем).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2.2 KiB
ADR 0015. Модельный день считается в часовом поясе счетчика
Дата: 28 августа 2026 года. Статус: принято. Реализация — тикет #39.
Решение
Модельные сутки считаются в часовом поясе счетчика UTC+4. EventDate обозначает
дату в этом поясе, а UTCEventTime — абсолютную метку времени. Граница
модельного дня приходится на полночь счетчика.
Суточная волна посетителя привязана к его местному времени. У гостя из другого пояса она сдвигается на разницу с поясом счетчика, но общая граница дня остается прежней.
Почему
Так устроена выгрузка Метрики: дата события уже посчитана в поясе счетчика. Полночь в этом поясе не разрезает утренние сессии в регионе мира. Регион можно выбирать независимо от технического пояса счетчика.
Для всего потока дня нужна одна граница суток. Местное время гостя описывает поведение в пределах этих суток, а отдельная дата для каждого посетителя не нужна.
Отклонено
В разделе 9 отклоненные варианты не зафиксированы.
Следствия
У ночных событий toDate(UTCEventTime) != EventDate. Хранилище берет день из
готового EventDate, а не выводит его из абсолютной метки. Поворот суточной
волны слегка размывает общий пик активности гостей из разных поясов.
Решение принято при исполнении тикета #39 и зафиксировано в спеке этапа 2, раздел 9.