Без хронометрии невозможно было бы определить конкретные дни и месяцы, точное время полудня или полуночи. От учета времени зависят самые разные структуры — от технологических компаний и спутниковых навигационных систем до вещательных организаций и астрономических служб.
В прошлой статье мы рассказывали, как синхронизируют технику с помощью дополнительных секунд. На всемирной конференции радиосвязи МСЭ (ВКР-23), которая проходила в Дубае с 20 ноября по 15 декабря, обсуждали замену високосной секунды на високосную минуту. И эксперты в очередной раз отложили решение «на потом». Но одно известно точно: рано или поздно от дополнительных секунд нужно будет избавиться. Подробности под катом.
Три шкалы времени: UT1, TAI и UTC
Любое событие можно определить тремя пространственными и одной временной координатами — следовательно, время должно быть нормативно определено и всемирно синхронизировано с высокой точностью. Шкала времени — это, по сути, упорядоченный набор отметок с соответствующей нумерацией.
В настоящее время используют три шкалы времени: UT1 (всемирное время), TAI (международное атомное время) и UTC (всемирное координированное время). Обсудим, в чем между ними разница.
UT1
Всемирное время (UT1) определяют на основе наблюдений за вращением Земли. Оно пропорционально углу поворота планеты вокруг своей оси. При этом коэффициент выбирают таким образом, чтобы 24 часа UT1 были близки к средней продолжительности суток. А фазу — так, чтобы ноль часов UT1 соответствовал средней полуночи на линии меридиана в Гринвиче.
Под секундой UT1 понимают 1/86400 средних солнечных суток. До 1960 года она была равна одной секунде в международной системе единиц (СИ). До 1972 года UT1, которое рассчитывается и поддерживается IERS, было общепринятой эталонной шкалой времени.
TAI
TAI — это временная шкала, которую определяют через атомную секунду — интервал, равный 9 192 637 770 периодам излучения атома цезия-133. Начало отсчета TAI согласовано таким образом, чтобы оно совпадало с UT1 от первого января 1958 года.
С тех пор TAI определяет международное бюро мер и весов, которое собирает и обрабатывает показания 450 атомных часов, расположенных в 85 странах. Однако вскоре появилась идея объединить различные шкалы, чтобы увеличить точность. Это привело к тому, что в 1972 году был принят новый координированный глобальный стандарт времени.
UTC
Колебания скорости вращения Земли приводят к расхождению между шкалами UT1 и TAI. IERS регулирует эту неточность с помощью дополнительных секунд. Их комбинация с UI1 и TAI и дает UTC, всемирное координированное время.
Хотя BIPM рассчитывает и распространяет стандартную шкалу времени UTC, пользователи по всему миру имеют доступ к локальным значениям UTC, определяемым национальными лабораториями. Они координируются как с UTC, так и друг с другом.
Почему важна синхронизация без дополнительных секунд
В современных сетях 5G синхронизация важна как никогда — и она будет играть еще более значимую роль в будущем. Например, в системах управления роботами на заводах.
Синхронизация важна и для работы дата-центров. Время помогает соотнести и упорядочить одновременные события на сотнях серверов. В сфере безопасности хронометрия нужна, например, для проверки сертификатов с коротким сроком действия и обнаружения вторжений.
Прерывистый характер UTC, из-за которого периодически нужно добавлять дополнительные секунды, влияет на экономику, кибербезопасность и современные отрасли промышленности, в основе которых — архитектура распределенных систем.
Подробнее о проблемах
Автоматизация и распределенные системы не могут стабильно работать из-за временных расхождений, которые вводит дополнительная секунда. Ситуация усугубляется отсутствием стандартов в «обслуживании високосных секунд», вялым диалогом между сообществом IT-специалистов и метрологами. Кроме того, нет единого подхода к предоставлению услуг с помощью глобальных навигационных спутниковых систем вроде GPS, Galileo, ГЛОНАСС, DORIS и BeiDou, а также региональных систем типа IRNSS.
Расхождения приводят к отказам ПО для IoT и устройств на базе Windows, Linux и Unix. Микропрограммное обеспечение каждого датчика основано на одной из этих систем. Внезапные сдвиги по времени побуждают ошибки низкоуровневой хронологии событий, которая определяет управление многозадачностью и другими процессами в системе.
Несоответствие хронологии может привести к «панике ядра» — компьютерной ошибке, после которой система не сможет быстро восстановиться:
В таких сценариях дополнительная секунда UTC может привести к эффекту домино: уронить электросвязь, энергосистему, сбоям в работе железных дорог и всему, что доступно воображению. Вероятно, в будущем дополнительная секунда UTC впервые станет отрицательной. Как отреагируют на это системы — сказать сложно.
Новая парадигма синхронизации времени
Есть два варианта обработки событий, связанных с введением дополнительной секунды: скачкообразное изменение времени или размазывание скачка. В большинстве случаев предпочтительней второй вариант — метод распределения по интервалу в несколько часов.
Вводимая дополнительная секунда обозначается как 23:59:60, то есть как время, не предусмотренное в большинстве современных цифровых систем. Это противоречие привело к широкому распространению особых методов, которые все чаще используются в качестве альтернативы дополнительной секунде. Например, Google размазывает дополнительную секунду по предыдущим 24 часам, Facebook — по последующим 18 часам, Microsoft — по предыдущим двум секундам, а Alibaba — по интервалу в 24 часа, на середину которого и приходится дополнительная секунда.
За период с 1972 года UTC обновляли 27 раз. Крайняя дата — 31 декабря 2016 года. Сегодня разница между UTC и TAI составляет 37 секунд.
Последствия и риски из-за корректировок привели к тому, что все чаще звучат призывы к проведению реформы UTC и отмене дополнительных секунд. Тема будущего всемирного координированного времени была вынесена на обсуждение международного союза электросвязи (МСЭ) еще в 1999 году. В то время Китай предложил лучше изучить этот вопрос и принять решение.
Впоследствии страны и организации продолжили обсуждение вопроса о дополнительной секунде на всемирной конференции радиосвязи в 2015 году, где было принято решение не вносить никаких изменений в UTC до 2023 года. Сегодня реформа приобрела неотложный характер.
Конечно, до вступления в силу високосной минуты пользователи должны успеть оценить и внести обновления в свои системы и программное обеспечение. При этом следует как-то сохранить связь UTC с UT1. В некоторых областях и отраслях, таких как астрономия, геодезия, космические исследования, по-прежнему используется UT1. Поэтому закрыть на него глаза не получится.
Возможно, эти тексты тоже вас заинтересуют:
→ Мониторинг на Python: как сохранить метрики в мультипроцессном режиме
→ Необычные ноутбуки: китайский тяжеловес с серверным AMD EPYC, RISC-V лэптоп и станция с 7 дисплеями
→ Предновогодние мини-ПК: 5 отличных девайсов на разные случаи жизни
Универсальная эталонная шкала времени
Вопрос о введении эталонной шкалы времени поднимали не раз. Главная задача заключается в том, чтобы сделать UTC непрерывной, а не ступенчатой шкалой атомного времени, какой она является сейчас.
На 27 заседании генеральной конференции по мерам и весам, которая проходила в ноябре 2022 года, решили сохранить существующую согласованность UTC с вращением Земли. Это значит, что нужно будет использовать более широкий диапазон допустимых отклонений, чем 0,9 секунды. Соответственно, вводить более значительные корректировки. Но последняя мера будет более редкой, чтобы можно было использовать UTC последующие 100 лет.
Сегодня BIPM, МСЭ-R и другие организации разрабатывают новый порядок, который должен вступить в силу в 2035 году. Он предусматривает установку нового допустимого расхождения UT1-UTC, чтобы UTC продолжало работу в текущих и будущих приложениях измерения времени.
Для адаптации к изменению UTC ряд пользователей, в том числе астрономическая, морская навигационная, подвижная и воздушная службы, потребовали дополнительное время на обновление систем. В случае с ГЛОНАСС период между принятием решения и реализацией должен составить не менее 15 лет.
Что думаете насчет дополнительной секунды вы? К каким последствиям она может привести в ваших системах? Поделитесь опытом и мнением в комментариях. А еще — с наступающим Новым годом!
Комментарии (24)
chnav
31.12.2023 13:56+2>> Почему важна синхронизация без дополнительных секунд... В современных сетях 5G синхронизация важна как никогда
Кто о чём, а вшивый о бане. Пусть решают свои местечковые проблемы своими местечковыми методами. И что это за IT такое которое неспособно обработать лишнюю целую секунду.
netch80
31.12.2023 13:56+25G это маленький пример. Не знаю, почему автор статьи взял его. И его можно решить очень грубо - да хоть порвать все разговоры в момент перехода.
Есть более серьёзные примеры. Все технологии непрерывного цикла с замером параметров, начиная с АЭС и химзаводов.
И что это за IT такое которое неспособно обработать лишнюю целую секунду
Вот такое вот IT. Которое экономит на тестировании, на сопровождении, всё, что можно и что нельзя. Я работал на таких проектах, где мы вводя мелкую новую фичу ломали фичи соседей и никто этого не видел до релиза, и они нам - точно так же:(
chnav
31.12.2023 13:56Ну это тем более странно, если системы реального времени завязаны на часы-минуты-секунды, в то время как нужен непрерывный счётчик времени. Leap Seconds по идее нужны только только для кросс-перевода в человеческие HHMMSS. Кстати в ГЛОНАСС не стали заморачиваться с високосными секундами, синхронизировали один раз и время идёт непрерывно.
netch80
31.12.2023 13:56Кстати в ГЛОНАСС не стали заморачиваться с високосными секундами, синхронизировали один раз и время идёт непрерывно.
GPS - точно так же, TAI время. PTP - точно так же. Но это не счёт в ядрах.
Ну это тем более странно, если системы реального времени завязаны на
часы-минуты-секунды, в то время как нужен непрерывный счётчик времени.Проблема в том, что база >99% систем реального времени, которые используются сейчас - это firm- и soft-realtime на базе чего-то Unix-подобного, в первую очередь Linux. Почему так - а потому что разработка на любом другом будет в разы дороже. А у Unix систем в принципе счёт в ядре в unixtime-без-вставных-секунд.
И тут при наличии багов лучше, кстати, подход BSD, которые вообще не пытаются эту секунду отрабатывать, возложив "растяжение" на длинные периоды (от 15 минут) средствами внешних NTP/etc. демонов. А вот Linux растягивает переходную секунду на две, и тут начинается полное ой.
sukhe
31.12.2023 13:56+10"Не стоит прогибаться под изменчивый мир..."
Давайте будем замедлять/ускорять вращение Земли, чтобы она совершала один оборот ровно за 86400 секунд ????
VladimirFarshatov
31.12.2023 13:56А не слишком ли большое расхождение в 37 секунд за менее чем 100лет? Земля замедляет или ускоряет свое вращение?
Krawler
31.12.2023 13:56+3https://ru.wikipedia.org/wiki/Дельта_T#О_неравномерности_вращения_Земли_вокруг_своей_оси
Да. Она замедляется. И этот процесс, насколько я помню, цикличенVladimirFarshatov
31.12.2023 13:56Да .. всё пытаюсмь понять когда вернется к нам герой фильма "Тот самый Мюнхаузен" (1979), как посмотрел впервые, так и стало интересно. Он там заявил что "Когда я вернусь, пусть будет 6 часов" .. "утра или вечера?" .. -Дня.
Вот, если замедляется, то реально скоро вернется. С Новым Годом всех! ;)
SimSonic
31.12.2023 13:56Там же на самом деле ещё есть нотка непредсказуемости. Вот, к примеру, Китай построил мегадамбу — Земля немного изменила скорость вращения ...
Wesha
31.12.2023 13:56+3"Мастерство программиста заключается не в том, чтобы писать программы, нормально работающие в отсутствие ошибок. Мастерство программиста заключается в том, чтобы писать программы, продолжающие нормально работать несмотря на все происходящие в системе ошибки."
*
Речь идёт не об ошибках, происходящих в окружении программы. Например, система управления сигналами светофора должна продолжать нормально работать, если на диске закончилось место для логов. Или, как в статье, не удалось получить точное время.
cortl
31.12.2023 13:56+1Какой смысл работать без логов? Как потом разгребать ДТП на этом перекрёстке при, внешне, нормальной работе светофора, который год работал без фиксации своих действий?
Надо было заблаговременно анализировать свободное дисковое пространство и сигнализировать куда надо.
А если закончится ОЗУ и swap?
Wesha
31.12.2023 13:56Какой смысл работать без логов?
Очень рад, что Вы не пишете ПО для критических систем вроде АЭС.
Надо было заблаговременно анализировать свободное дисковое пространство и сигнализировать куда надо.
Вот именно. Но даже такой более чем очевидный вариант развития событий в настоящее время мало кто предусматривает.
cortl
31.12.2023 13:56+3Печально, что разработчику ПО для АЭС нечего сказать по третьему пункту.
Wesha
31.12.2023 13:56Печально, что вещи уровня "не надо делать ЭТО мимо унитаза" для современных программистов нужно особо оговаривать.
cortl
31.12.2023 13:56А здесь уже начинают действовать дедлайны. Делают то, на что выделено время. Шаг влево, шаг вправо - расстрел. Контроль свободного пространства в ПЗУ это отдельная фича, это не задача разработкти логов. Когда перед разработчиком ставится задача сходить в туалет зачастую там нет даже унитаза. Хорошо, если фановая труба есть... А сроки никто не отменял.
Wesha
31.12.2023 13:56А здесь уже начинают действовать дедлайны.
А здесь уже виноват менеджер — если он дал невыполнимый дедлайн, то такой менеджер — неправильный.
Так не работает.
Не знаю, как Ваш, а мой менеджер служит посредником между мной и человеками, а также бульдозером, расчищающим препятствия (обычно — в виде человеков и их непонятных желаний) у меня на пути. Если у Вас не так — ну что ж, примите мои соболезнования.
А после двух-трёх ситуаций когда из такой наспех проложенной трубы нафонтанировало так, что всей конторой две недели оттирались — к моим предупреждениям прислушиваются.
cortl
31.12.2023 13:56Всякие менеджеры у меня бывали. И поэтому говорю, что нельзя всё валить на разработчика. Кроме него ещё много слабых звеньев может оказаться: заказчик, менеджер, архитектор, аналитик, тестировщик.
netch80
31.12.2023 13:56+3Картинка паники ядра от совсем другой проблемы чем вставная секунда:) ну и в 2015 паники не было, были безвыходные заклины таймеровнедора.
Воспроизводить ситуацию как лишней, так и удалённой секунды тривиально, и проблема в том, что никто не хочет это делать.
runaway
31.12.2023 13:56Почему все решили вводить дополнительную високосную секунду вместо того, чтоб время от времени не отсекать лишнюю 59-ю? Это же явно проще. Разделить равномерно годовой цикл вращения Земли с маленьким запасом, и раз в несколько лет по одной секунде не досчитываться.
Gradiens
31.12.2023 13:56+1Простите за вопрос от чайника, перевести стрелки часов чтобы что?
Ну то есть, как я понял из статьи, сейчас время расхождения между атомным и астрономическим таймерами уже 37 секунд. При этом все как-то функционирует. Почему бы не оставить все как есть, вместо того, чтобы подвергать массу важных для человечества систем риску сбоев?
Возможно, это архитектурно неверно, но чем плохо это накапливающееся расхождение? Пусть копится.
mikryukovsl
31.12.2023 13:56Этот мир это аквариум, а учёные это просто паразиты плавающие в нём, чего они там могут повлиять или указать, только курам насмех. Не утверждаю что оставшийся хомяческий сброд что то понимает и на что то может повлиять, они даже в Ленина верят Гагарина и Путина.
Wesha
31.12.2023 13:56они даже в Ленина верят Гагарина и Путина
Ну с двумя ещё понятно, но чем Гагарин-то не угодил? Он что, в космос не летал, потому что об хрустальный свод разбился бы?
mac_sim
31.12.2023 13:56На мой взгляд в статье не хватает технических деталей. Такая статья была бы хороша для не специализированного научно популярного ресурса. Но Хабр всё-таки технарьское сообщество, аудитории интересны технические детали проблем, сравнительный анализ подходов к их решению.
Actaeon
Поскольку в компьютере все равно стоит осциллятор,на который вращение Земли не влияет, - переходите на TAI,Международная Служба Вращения Земли потом формулу для поправок выведет, зато заказов на исправление ПО будет ....