Стрики в трекере привычек: задайте правила и корректно работайте с часовыми поясами

Почему стрики быстро становятся запутанными

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

Большая часть путаницы связана с одним тихим вопросом, на который приложение обязано ответить: что считается днём?

Если вы не определите это явно, пользователи будут получать неожиданные сбросы («я же сделал это сегодня!») или случайные двойные отметки (отметка поздно ночью, затем ещё одна после полуночи). Путешествия делают ситуацию ещё хуже. Пользователь отмечает выполнение в 23:30 в Нью‑Йорке, летит в Лос‑Анджелес и открывает приложение в 21:15 по местному времени. Засчитано ли это за «сегодня»? Или граница дня сместилась?

Цель не в том, чтобы придумать технически «чистейшую» систему стриков. Цель — правила, которые кажутся справедливыми, ведут себя одинаково и их можно объяснить в приложении в одну‑две фразы.

Если вы строите с помощью AI‑инструментов, логика стриков — частое место, где появляются крайние случаи. Прототипы обычно покрывают «счастливый путь», если вы не заставите их учитывать сценарии вроде путешествий, поздних отметок, перехода на летнее время и смены системного времени.

Решите, что в вашем приложении значит «день»

Стрики кажутся справедливыми, когда приложение явно говорит, что считается днём. Если оставить это расплывчатым, два человека могут сделать одно и то же действие и получить разные результаты.

Сначала выберите, чей часы вы используете:

• Локальный день пользователя: отметка засчитывается по текущей локальной календарной дате пользователя. Это естественно, но требует аккуратной обработки смены часовых поясов.
• День по UTC: отметка засчитывается по дате в UTC. Это проще реализовать, но может ощущаться странно (вечерние отметки попадут в «завтра»).

Далее выберите границу дня. Большинство приложений использует полночь‑по‑полночи в выбранной зоне, но есть разумные альтернативы:

• Полночь: знакомо и просто объяснить.
• Скользящие 24 часа: математически последовательно, но сбивает с толку, потому что «день» постоянно движется.
• Пользовательский порог (например, 3:00): гуманнее для сов и сменных смен, если правило последовательно и объяснено.

Порог в полночь может наказать того, кто завершил привычку в 00:30 после поздней смены. Порог в 3:00 может показаться более «человечным», но только при простом объяснении.

Запишите правило в одну фразу, которую пользователь сможет повторить:

«Ваш стрик засчитывается один раз в календарный день; день идёт с 03:00 до 02:59 по вашему текущему часовому поясу.»

Будьте строги с этим правилом при работе с AI‑инструментами. Многие сгенерированные прототипы случайно смешивают локальное время и UTC, что приводит к внезапным сбросам, которых пользователи не прощают.

Опишите правила стрика простым языком

Большинство багов стриков начинаются с формулировок. Если два человека могут прочитать ваши правила и по‑разному понять результат, кто‑то останется разочарован.

Решите, что значит «завершение»:

• Это одна отметка в день или можно отмечаться несколько раз, но кредит даётся один раз?
• Если привычка считает количество (например, «выпить 8 стаканов»), учитывается ли частичный прогресс для продления стрика, или только 100% день?

Затем определите, когда стрик начинается. Некоторые приложения начинают с первой отметки пользователя. Другие начинают только после выполнения полного дня. Любой подход допустим — важна последовательность в онбординге, статистике и уведомлениях.

Простой набор правил по умолчанию выглядит так:

• День засчитывается, если привычка помечена выполненной хотя бы один раз в этот день.
• Частичный прогресс сохраняется, но не продлевает стрик, если привычка не достигла 100%.
• Стрик начинается в день первой выполненной отметки.
• Стрик прерывается, если проходит полный календарный день без выполнения.

Наконец, решите, когда UI обновляется. Пользователи замечают, когда бейдж стрика показывает 7, а календарь всё ещё выглядит незавершённым. Выберите один момент для изменения значения стрика (часто — сразу после отметки) и применяйте ту же логику везде.

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

Стрики перестают быть простыми с первой отметки в 00:05, поездки или правки «вчера». Выберите модель заранее, зафиксируйте её и рассматривайте как продуктовое решение, а не как деталь имплементации в последний момент.

1) Строгие стрики (чётко, но без пощады)

Строго означает: вы обязаны выполнить привычку в пределах определённого дня; пропуск дня сбрасывает стрик. Поздние отметки после полуночи засчитываются за новый день, а не за предыдущий.

Эта модель проста для объяснения и расчёта, но раздражает тех, кто занимается привычками ночью.

2) Гибкие стрики (ближе к реальной жизни)

Гибкость помогает пользователю сохранять инерцию. Частые подходы:

• Буфер поздней ночи (например, отметки до 02:00 всё ещё считаются за «вчера»).
• Ограниченный «спасительный» день (например, один пропущенный день допустим за определённый период).

Такие правила уменьшают моменты «я сделал это, но приложение наказало меня».

Зафиксируйте решения, которые порождают споры

Конфликты почти всегда возникают из одной группы решений:

• Поздние отметки: засчитываются ли они за предыдущий или текущий день?
• Пропущенные дни: немедленный сброс или ограниченное правило «спасения»?
• Правки/задним числом: запрещены, разрешены в коротком окне или разрешены с явным флагом?
• Повторы: ровно один раз в день или «хотя бы один раз»?

Что бы вы ни выбрали, покажите это в UI, чтобы никто не удивлялся. Короткая строка под числом стрика помогает («Поздние отметки засчитываются до 02:00»). Если правка изменит стрик, показывайте подтверждение вместо молчалого перерасчёта.

Данные, которые нужно хранить, чтобы стрики были надёжными

Стрик надёжен ровно настолько, насколько надёжны факты, на которых он основан. Храните неизменяемые факты, а затем выводите ключи дня и подсчёт стрика из этих фактов.

Начните с записи каждой отметки как события. Каждое событие должно включать временную метку в UTC. UTC — ваша «истина», потому что она остаётся корректной, даже если пользователь путешествует, меняет время телефона или перескакивает через переход на летнее время.

Далее храните часовой пояс пользователя и источник его получения. Часовой пояс — не просто ярлык: это часть того, как вы интерпретируете один и тот же UTC‑таймстамп как локальную дату.

Простой набор полей, который предотвращает большинство споров:

• checkin_at_utc (timestamp)
• user_timezone (например, America/New_York)
• timezone_source (device, manual, inferred)
• local_date_key (опционально, вычисляется при записи)
• created_at_utc и created_by (для аудита)

Вы также можете хранить ежедневную суммарную строку, индексированную по (user_id, habit_id, local_date), если нужны быстрые проверки «сделал ли он это сегодня?». Обращайтесь с ней как с производным сводом, а не с истиной.

Если вы разрешаете правки в прошлое, ведите след аудита. Большинство обращений «мой стрик сломался!» происходит из‑за тихого бэкафилла.

Как строить с AI‑инструментами и не пропустить крайние случаи

Начните с крошечного спецификации простым языком. Держите её короткой, но конкретной:

• Что считается «сделано»
• Когда начинается и заканчивается день
• Что происходит при путешествиях
• Можно ли засчитать позднюю отметку

Эта спецификация становится вашей единственной истиной.

Когда вы даёте задачу AI‑инструменту для кода, просите модель дать модель данных и небольшой набор эндпоинтов. Скажите, чтобы логика часовых поясов была на сервере и сервер возвращал рассчитанные на сервере результаты стриков (не то, что «вычислено в UI»). UI должен отображать ответы, а не придумывать их.

Сгенерируйте тесты до того, как начнёте строить экран календаря. Покройте:

• Переход через полночь
• Смена часовых поясов
• Изменения из‑за DST

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

Добавьте лёгкое логирование вокруг перерасчёта стриков: user ID, habit ID, сохранённый часовой пояс, вычисленный ключ дня и итоговое значение стрика. Когда кто‑то жалуется «мой стрик сбросился», вы сможете воспроизвести, что случилось.

Обработка путешествий и смены часовых поясов

Путешествия — место, где стрики часто кажутся несправедливыми. Пользователь сделал привычку, но приложение использует другой часовой пояс, и стрик переворачивается.

Решите, кто контролирует правило часового пояса. Самый чистый подход — сделать это настройкой пользователя с разумным значением по умолчанию.

Выберите правило для поездок (и придерживайтесь его)

Большинство приложений выбирают один из этих вариантов:

• Следовать текущему локальному времени: «день» определяется текущим часовым поясом телефона.
• Фиксировать домашний часовой пояс: «день» всегда по выбранной зоне.
• Ручной оверрайд: пользователь выбирает зону в настройках, она остаётся, пока он не поменяет её.

Локальное время кажется естественным, когда пользователь живёт где‑то долго. Фиксация домашней зоны избегает странностей на коротких поездках, где перелёты создают необычно длинные или короткие «дни».

Избегайте разногласий клиент vs сервер (особенно офлайн)

Смена часового пояса может дать два ответа: что показывает телефон и что позже примет сервер. Рассматривайте каждую отметку как событие с единственным источником истины.

Практическое правило: когда пользователь нажимает «Готово», сохраните и (1) точную временную метку, и (2) часовой пояс, использованный для вычисления ключа дня. Если пользователь офлайн, используйте последнее известное правило и не перерасчитывайте старые отметки после восстановления соединения.

В настройках ясно объясняйте правило простыми словами:

«Ваш стрик сбрасывается на основе: Текущего локального времени»

или

«Домашний часовой пояс: America/New_York»

Добавьте однострочное предупреждение: «Изменение этого параметра может сместить, к каким дням относились ваши прошлые отметки.»

Переход на летнее/зимнее время и странные календарные дни

Переход на DST создаёт «странные» дни: некоторые по 23 часа (переход вперёд), некоторые по 25 часов (переход назад). Если логика стриков предполагает, что каждый день ровно 24 часа, рано или поздно вы удивите пользователей сбросом или дополнительным днём стрика.

Самая большая ловушка — считать стрики вычитанием часов от «сейчас» (например, «последняя отметка была в пределах 24 часов»). В 23‑часовой день 24 часа могут отнести вас в «вчера», хотя пользователь отметил в правильный календарный день. В 25‑часовой день две отметки, которые интуитивно кажутся в разные дни, всё ещё могут быть «в пределах 24 часов».

Как избежать багов из‑за DST

Обращайтесь со стриками как с календарной задачей, а не как с арифметикой. Определяйте «день» пользователя по часовому поясу и границе дня, затем сравнивайте календарные даты в этой зоне.

Простое правило, которое выживает при DST:

«День засчитывается, если у пользователя есть хотя бы одна отметка между 00:00 и 23:59:59 в выбранном часовом поясе.»

Тестируйте DST преднамеренно:

• День «spring forward» как минимум в двух зонах (в одной с DST, в другой без)
• День «fall back», включая отметки вокруг повторяющегося часа
• Отметки прямо до и сразу после полуночи

Уведомления в дни смены DST

Напоминания могут казаться «неправильными» на уик‑эндах с DST. Выберите одно поведение и держитесь его. Большинство трекеров привычек сохраняют напоминания на одном и том же локальном времени (8:00 остаётся 8:00), потому что так ожидает пользователь.

Частые ошибки, разрушающие доверие к стрикам

Доверие рушится, когда календарь не совпадает с тем, что считает ваше приложение. Быстрейший способ потерять уверенность — когда UI показывает «Сделано сегодня», но стрик всё равно падает.

Распространённые причины:

• Подсчёт дней на сервере в UTC при показе локального календаря
• Вычисления стриков на клиенте, в то время как сервер хранит истину
• Пересчёты стриков в нескольких местах (профиль, главный экран, фоновые задания) с чуть разными правилами
• Неограниченное задним числом добавление, которое делает стрики бессмысленными
• Тесты, которые покрывают только «нормальные недели» и игнорируют граничные даты

Правки задним числом должны иметь ограничения. Небольшое окно (например, «вы можете пометить вчера до полудня следующего дня») честно. Неограниченные правки приглашают споры.

Не пропускайте в тестах граничные даты: границы месяцев, високосные дни и отсутствующие/повторяющиеся часы вокруг DST.

Быстрый чек‑лист перед выпуском

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

Вот предпусковой чек‑лист, который ловит большинство проблем:

• Однофразное правило, определяющее «что считается сегодня», показанное в UI
• Отметки сохранены в UTC плюс часовой пояс пользователя при отметке
• Один источник истины для расчёта стрика (единая функция или сервис)
• Тесты на поездки, DST, офлайн‑отметки, правки и поздние ночные активности возле порога
• Согласованность между устройствами: UI совпадает с результатами сервера, даже если системное время устройства неверно

Проверьте простой сценарий: пользователь отмечает в 23:58, затем снова в 00:05. Ваше приложение должно вести себя одинаково на мобильном и в вебе, и стрик должен обновиться одинаково после обновления.

Пример сценария: путешествие без сброса стрика

Пользователь в Лос‑Анджелесе. В понедельник вечером он выполняет привычку в 23:50 по местному времени и видит: «Стрик: 12 дней. Сегодня выполнено.»

Он летит в Нью‑Йорк и приземляется поздно. После полуночи телефон уже показывает Eastern Time.

Если ваше правило — «день определяется текущей локальной датой пользователя» (что обычно ожидается), то понедельник всё ещё должен выглядеть завершённым в эту ночь. Утром в Нью‑Йорке вторник — новый день и будет пуст до тех пор, пока он не отметится.

Если он отметится снова в 00:10 по Нью‑Йорку, вы должны решить:

• Строгая модель: эта отметка считается за вторник, стрик становится 13.
• Окно снисхождения: предложить выбор («Зачесть за понедельник» или «За вторник»), но только если это можно ясно объяснить.

Что бы вы ни выбрали, делайте решение дебагируемым. Когда техническая поддержка получает «мой стрик сломался», ей должно быть видно:

• Временную метку в UTC и локальное время пользователя
• Часовой пояс, использованный для решения (включая смещение)
• Вычисленный ключ дня (например, 2026-01-21)
• Применялось ли окно снисхождения
• За какой день отметка была засчитана

Следующие шаги, чтобы сделать AI‑построенный трекер привычек готовым к продакшну

Относитесь к логике стриков как к логике биллинга: мелкие детали важны, и будущие правки могут её сломать.

Напишите одностраничную спецификацию, которую можно вставлять в подсказки и делиться с коллегой. Держите её простым языком. Включите границу дня, что считается «сделано» и что происходит при пропуске дня.

Защитите её небольшим набором тестов (не нужно 200 тестов). Выберите 6–10, покрывающих отметки около полуночи, сбросы из‑за пропуска дня, переключения часовых поясов, DST и правки/заполнение задним числом (если вы это разрешаете).

Если вы унаследовали AI‑сгенерированный прототип, где обработка времени непоследовательна, аутентификация сломана или код трудно поддерживать, FixMyMess (fixmymess.ai) может провести бесплатный аудит кода и помочь диагностировать и исправить логику, чтобы вы могли выпускать с уверенностью.