Мир отказался от високосных секунд: что это значит для IT

15 октября 2026 года в Версале Генеральная конференция по мерам и весам приняла резолюцию об отмене високосных секунд. С 20 мая 2027 года UTC станет непрерывной шкалой времени: секунды больше не будут ни добавляться, ни вычитаться.

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

Что такое високосная секунда

В основе современного времени лежат две разные шкалы.

Атомное время равномерно: его отсчитывают сверхточные атомные часы. Астрономическое время UT1 привязано к вращению Земли. Проблема в том, что Земля вращается неравномерно: на это влияют приливы, движение атмосферы, процессы в недрах и другие факторы.

В 1972 году появился компромисс — UTC. Когда расхождение между атомным и астрономическим временем становилось критическим, в UTC добавляли одну дополнительную секунду. С 1972 года високосную секунду добавляли 27 раз. Последний раз это произошло 31 декабря 2016 года.

Атомное время
      ↓
   UTC + високосная секунда
      ↓
Астрономическое время UT1

Идея была простой: сохранить связь с вращением Земли, но не заставлять людей и технику постоянно менять часы. На практике для IT эта «дополнительная секунда» оказалась источником редких, но болезненных сбоев.

Почему это ломало IT

Високосная секунда создаёт метку 23:59:60 — время, которого многие компьютерные системы не ожидают. Разные операционные системы, библиотеки, СУБД, планировщики и распределённые сервисы могут обработать её по-разному.

В результате могут возникать:

• рассинхронизация часов между узлами кластера;
• нарушение порядка событий в логах и трассировках;
• зависание очередей и планировщиков;
• ошибки валидации даты и времени;
• сбои в распределённых транзакциях;
• деградация систем, чувствительных к точному порядку операций.

Известные примеры:

• 2012 год: високосная секунда вызвала сбои у Reddit, LinkedIn, Yelp и в системе бронирования Qantas. Проблемы проявились в Java, Hadoop, Cassandra и ядре Linux.
• 2016 год: Cloudflare и другие пользователи облачных сервисов столкнулись со сбоями и задержками.

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

Как индустрия пыталась решить проблему сама

Крупные технологические компании применяли leap smear — «размазывание» високосной секунды. Вместо того чтобы добавить секунду одним резким шагом, они плавно замедляли или ускоряли часы в течение нескольких часов.

Это снижало риск мгновенного сбоя, но создавало другую проблему: разные платформы временно расходились в показаниях времени. Для распределённых систем это означало, что «единое UTC» на период smear переставало быть действительно единым.

Обычный UTC:
23:59:59 → 23:59:60 → 00:00:00

Leap smear:
23:59:59 → 23:59:59.001 → 23:59:59.002 → ... → 00:00:00

То есть индустрия не устранила проблему, а замаскировала её. Каждая крупная платформа получила собственную «временную реальность».

Главный страх: отрицательная високосная секунда

До недавнего времени существовал риск, что впервые потребуется не добавить, а вычесть секунду. Земля в последние годы вращалась быстрее, чем ожидалось, поэтому расхождение между UT1 и UTC могло потребовать корректировки в обратную сторону.

Положительную високосную секунду индустрия переживала 27 раз. Отрицательную — ни разу.

Именно неопределённость поведения огромного парка систем в этой ситуации делала риск особенно серьёзным. Системы, которые хотя бы частично готовы к 23:59:60, могут оказаться совершенно не готовы к пропуску секунды.

Почему была позиция России

Российская спутниковая система ГЛОНАСС, в отличие от американского GPS и европейского Galileo, изначально построена с учётом високосных секунд. Для её полной перестройки требуется длительный переходный период.

Россия предлагала отсрочку до 2040 года, но это предложение не прошло. При этом проблема не является исключительно российской: високосные секунды так или иначе учитывают отдельные телеком-стандарты, финансовые протоколы и legacy-системы.

Поэтому переход затронет не только ГЛОНАСС, но и другие системы, в которых время исторически завязано на астрономическую шкалу.

Что изменится с 2027 года

С 20 мая 2027 года UTC становится непрерывной шкалой. Високосные секунды больше не будут добавляться.

Допустимое расхождение между UTC и астрономическим временем UT1 увеличивается до 3 600 секунд, то есть до одного часа.

Это не означает, что UTC и астрономическое время всегда будут совпадать. Напротив, система сознательно допускает постепенное расхождение — до одного часа.

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

Что делать разработчикам уже сейчас

1. Проверить обработку 23:59:60

Найдите в системе все места, где происходит парсинг, валидация, сравнение или форматирование времени. Особое внимание уделите:

• парсерам дат;
• планировщикам задач;
• ETL-процессам;
• интеграциям через API;
• очередям сообщений;
• журналированию и трассировке;
• cron-задачам и распределённым блокировкам.

2. Уточнить поведение облачного провайдера

Если вы используете облачную инфраструктуру, выясните:

• применяет ли провайдер leap smear;
• какой алгоритм он использует;
• как это влияет на метки времени в логах, событиях и метриках;
• как поведёт себя ваша система при расхождении времени между сервисами.

3. Проверить NTP-инфраструктуру

Проверьте серверы времени, политики синхронизации, мониторинг рассинхронизации и поведение системы при скачке времени.

Полезные вопросы для ревизии:

• Какие NTP-серверы используются?
• Какой допустимый clock skew установлен?
• Что произойдёт при резкой коррекции времени?
• Есть ли алерты на рассинхронизацию?
• Как система обрабатывает события, у которых время «ушло назад»?

4. Проверить библиотеки и рантаймы

Високосные секунды могут по-разному обрабатываться в Java Time, Linux kernel, базах данных, брокерах сообщений, планировщиках и SDK. Не стоит считать, что если ОС пережила прошлую високосную секунду, то и весь стек приложения готов к ней.

5. Заложить отказ от временных костылей

Если в коде уже есть ветки для leap second, smear или особых правил синхронизации, зафиксируйте срок их вывода из эксплуатации после 2027 года.

Это хороший кандидат в технический долг:

Задача: убрать обработку leap second
Условие: после 20 мая 2027 года
Ответственный: команда платформы
Проверка: нагрузочные и интеграционные тесты синхронизации времени

6. Не путать UTC и локальное время

Практическое правило остаётся прежним:

• храните события в UTC;
• передавайте время между сервисами в UTC;
• применяйте часовые пояса только на границе пользовательского интерфейса;
• не используйте локальное время как ключ порядка событий.

Чек-лист для архитектора и SRE

• Найдены все компоненты, зависящие от точного времени.
• Проверена обработка 23:59:60.
• Определён источник времени: NTP, облачный time service или внутренний сервер.
• Проверена политика leap smear у провайдера.
• Настроен мониторинг clock skew и NTP drift.
• Проверено поведение при скачке времени вперёд и назад.
• Зафиксированы временные костыли, которые можно убрать после 2027 года.
• Проверены интеграции с внешними системами, которые могут продолжать учитывать leap seconds.

Моё резюме

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

Отмена високосной секунды не сделает время идеальным. Появится новая, гораздо более медленная форма расхождения между UTC и астрономическим временем. Но для IT это всё равно важная победа предсказуемости: меньше редких исключений, меньше временных костылей и меньше причин для аварий в самый неподходящий момент.