Часовые пояса: Timezone и локальное время

По умолчанию robfig/cron интерпретирует все выражения в time.Local — зоне процесса Go. Откуда она берётся: из переменной окружения TZ, а если та не задана, из системного файла /etc/localtime. На ноутбуке это ваша географическая зона, в контейнере почти наверняка UTC, на старом сервере — что угодно. Из этого следует, что cron timezone без явного указания — это зона сервера, а не зона бизнеса. Явное решение — конструктор: cron.New(cron.WithLocation(loc)), где loc — значение *time.Location, полученное через time.LoadLocation по имени из базы IANA. Одна строка, и весь планировщик говорит на одном языке: выражения парсятся в этой зоне, тики вычисляются в ней же. Если сервис весь живёт в одном часовом поясе — например, внутренние отчёты компании в Берлине — этого достаточно, и дальше можно не читать. Остальным — про задачи в чужих зонах.

Когда в одном сервисе живут задачи в разных зонах — отчёт по берлинскому времени, синхронизация по нью-йоркскому рынку, напоминания по местному времени пользователей — переносить весь планировщик в одну зону недостаточно. Для этого в v3 есть префикс CRON_TZ прямо в выражении: строка вида CRON_TZ=Asia/Tokyo 30 4 * означает «в 04:30 токийского времени», и работает независимо от зоны самого планировщика. Префикс понимает штатный парсер библиотеки — это не строковая обработка на вашей стороне, и ошибка в имени зоны вернётся из AddFunc сразу на старте, а не в первый тик. Правило приоритета простое: зона из CRON_TZ конкретной задачи сильнее зоны планировщика, а зона планировщика сильнее time.Local. Есть и старый префикс TZ= — он поддерживается для совместимости, но документация рекомендует CRON_TZ, и новый код лучше писать по ней.

Зоны со сезонным переводом часов — Европа, Америка, Австралия — вносят в расписание два особенных момента в году. Весной час выкидывается: в ночь перехода время с двух до трёх не существует, и задача, стоящая на 02:30, в эту ночь попадает в несуществующий момент. Как это разрешится — вопрос к пакету time: документация time.Date честно пишет, что для несуществующего времени выбор зоны не гарантирован, то есть тик случится, но в соседний момент. Осенью наоборот: час наступает дважды, и момент 02:30 неоднозначен. Отсюда практические правила: ночные задачи не ставят на окно перехода (примерно 02:00–03:00 в зонах с DST), а задачи, которым важна точность до минуты, тестируют на даты переходов. Российским зонам сейчас проще: сезонные переводы в них отменены с 2014 года, и Europe/Moscow круглый год UTC+3. Но если бизнес в Европе или США — переходы обязаны быть частью плана, а в логах вокруг дат переходов полезно держать повышенное внимание хотя бы в первые недели после релиза.

Когда зоны меняются от пользователя к пользователю — напоминания в боте, дайджесты по местному утру, — правило одно: хранить и считать в UTC, конвертировать на границе. В базах данных время сохраняется в UTC без зоны; в задаче вычисляется целевой момент — user.Zone.Load или LoadLocation по строке зоны профиля; момент интерпретируется в этой зоне. Префикс CRON_TZ здесь не помощник: он предполагает фиксированную зону, известную на старте, а у вас их столько же, сколько пользователей. Поэтому пользовательские напоминания обычно устроены иначе: одна задача тикает почасово или поминутно, выбирает из базы тех, у кого местное время подошло, и конвертирует время сравнения в их зоны. Расход — один тик вместо тысячи расписаний; зато зона меняется в базе данных, а не в коде, и новый пользователь не требует перерегистрации задач. Такую схему мы подробно собирали в уроке про напоминания в Telegram-боте; механика самого пакета time — зоны, In, ParseInLocation — разобрана в уроке про time и таймеры.