Часовой пояс: как мелочь однажды сломала картину дня

Время — это, казалось бы, самая простая величина в трекере рабочего времени. Есть отметка “начал работать”, есть отметка “закончил”, есть часы между ними. На практике время — одно из немногих мест, где очень легко незаметно ошибиться, и ошибка не будет выглядеть как ошибка. Она будет выглядеть как обычная цифра на экране, просто неправильная.

Почему вообще возникает разница

Внутри DevPace все временные метки хранятся и передаются между сервером и приложением в UTC — это стандартная практика, и в этом нет ничего специфичного для DevPace. Проблема начинается на последнем шаге, когда UTC нужно превратить в конкретный час на таймлайне или в подпись “ваш лучший час — с 10 до 11”. Тут нужно выбрать, чей часовой пояс использовать.

Кажется естественным взять часовой пояс браузера или операционной системы — он всегда под рукой, его не нужно никуда сохранять. Именно так многие сервисы и поступают. Но браузер и ОС показывают не пояс человека, а пояс устройства в данный момент, а это не одно и то же. Рабочий ноутбук может быть настроен на другой регион, чем тот, где человек физически находится. Человек может уехать в командировку или в отпуск, не трогая при этом настройки Windows. Виртуальная машина или корпоративный образ вообще может иметь часовой пояс, который никто из сотрудников никогда не задумывался менять.

Как это устроено в DevPace

Поэтому DevPace различает часовой пояс аккаунта и часовой пояс устройства сознательно. При регистрации человек задаёт свой часовой пояс — это и есть та единственная точка отсчёта, которая используется для всего: для того, где на таймлайне рисуется граница часа, для расчёта, какой час дня был самым продуктивным, для дневных и недельных границ агрегации. Часовой пояс браузера при этом никак не участвует в расчётах — он попросту не запрашивается для этой цели. Это осознанное архитектурное решение, а не случайное совпадение: данные должны описывать день человека, а не день его текущего устройства.

Реальный случай

Один из таких сценариев был найден и исправлен на практике, а не придуман заранее. Аккаунт был зарегистрирован с часовым поясом Europe/Moscow, а браузер в момент открытия дашборда был выставлен на America/New_York — обычная ситуация для рабочего устройства, которое когда-то настраивали или использовали в поездке. Проблема была не в том, где хранились данные: сервер, как и положено, отдавал метки в UTC. Проблема была в одном конкретном экране на фронтенде — он, в отличие от остальных, брал часовой пояс не из профиля аккаунта, а напрямую из браузера, и уже на этом шаге переводил UTC в локальное время не того пояса. Разница в восемь часов означала, что активность, реально происходившая, скажем, в 18:00 по Москве, подписывалась как час ближе к полудню — и, соответственно, “лучший час” на графике указывал не на то время, когда человек на самом деле работал глубже всего.

Ошибка такого рода коварна именно тем, что она не ломает интерфейс и не выглядит как баг. Цифры остаются на своих местах, часы на графике идут по порядку, всё выглядит правдоподобно — просто подпись у столбика не та. Заметить это можно только сверив показанный час с тем, что человек помнит о своём собственном дне — именно так расхождение и обнаружилось. Исправление свелось к тому, чтобы убрать у этого экрана собственный источник часового пояса и подключить его к тому же полю аккаунта, которым уже пользовались таймлайн и остальная аналитика.

Последовательность работы на реальной временной шкале в DevPace — время строго в часовом поясе аккаунта

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

Почему это важно, а не просто дотошность

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

Поэтому в DevPace это правило зафиксировано на уровне архитектуры, а не на уровне договорённости между разработчиками: единственный источник правды для отображения времени — часовой пояс аккаунта, и точка.

Если хотите видеть свои часы именно так, как они были на самом деле — Посмотреть демо.

Смотрите также

Опубликовано: 3 июня 2026 г.