av
3d24248075
- каждая запись каталога задач получила тип вместо тега kind: и префикса заголовка; секция роадмапа «Разработка» стала «Сопровождением», порядок секций канонический - поправлены протухшие факты: нереализованные маршруты Read API, MCP и `healthlog import`, словарь слоёв в инварианте, семантика гейта по покрытию диффа, периметр перестал дублировать security.md - замер слияния переведён с находки 49 на находку 54, заполнены Purpose спек storage и parsing
23 lines
1.7 KiB
Markdown
23 lines
1.7 KiB
Markdown
# 🔬 Что считать сутками при смене часового пояса
|
|
|
|
- **Тип:** research
|
|
- **Категория:** Ядро
|
|
- **Зачем:** Шаги за день — базовый запрос трекера и игры, но чей это день при перелёте, не решено
|
|
- **Теги:** goal:read-api
|
|
|
|
«Шаги за день» — базовый запрос трекера и фитнес-игры. Но точка несёт метку с
|
|
офсетом исходной зоны, и при перелёте сутки перестают быть однозначными: день
|
|
по локальному времени в момент измерения, по текущей зоне телефона или по
|
|
фиксированной зоне пользователя — три разных числа.
|
|
|
|
Apple эту неоднозначность не решает, а перекладывает: в экспорте у записи есть
|
|
и время, и офсет. Мы храним так же — значит выбор всплывает ровно в момент
|
|
свёртки.
|
|
|
|
Почему идея, а не задача: непонятно, что должно стать наблюдаемо иначе. Нужно
|
|
решить, чей это выбор — сервера (одна зона в конфиге), клиента (параметр
|
|
запроса) или обоих (умолчание плюс переопределение).
|
|
|
|
Вопрос не гипотетический: походы и хайкинг из второго сценария — это как раз
|
|
поездки со сменой зоны.
|