Человечество привыкло измерять время циклами: 24 часа прошло, значит наступил новый день, семь дней закончились — началась неделя, четыре недели — месяц, 12 месяцев — год. Однако этот социальный стереотип работает только в тех сферах, где не важна посекундная точность. Коллеги поймут, если вы назначите встречу на четыре часа, а вот разговор со сложными компьютерными системами требует атомной пунктуальности.
Сегодня человечество сильно зависит от машин — где бы мы были без систем связи и искусственного интеллекта, который создал вакцину от COVID — а значит и от времени, которое устанавливают их разработчики. Как программисты отменяют секунды, вызывают панику и откладывают проблемы до 2486 года — читайте в нашем материале.
Никаких високосных секунд
Самым точным мерилом времени на Земле принято считать атомные часы. Внутри них находится кусок кварца, атомы которого колеблются с частотой примерно пять миллионов движений в секунду. Часы получают электрический импульс, который выводит колебательную систему из равновесия и позволяет считать время с очень высокой точностью. За счет подобного устройства атомные часы не зависят от вращения Земли вокруг своей оси, и именно по ним ученые судят об изменениях в движении планеты.
Земля представляет собой далеко не идеальную форму с абсолютным равновесием и постоянным положением оси. Кроме того, на нее с разной силой действует гравитация ближайших космических объектов, например, Луны. Поэтому скорость вращения нашей планеты регулярно меняется. Когда разница между атомными часами и периодом вращения «Голубого» шара становится критичной, ученые вводят добавочную или високосную секунду.
Казалось бы, отличное решение проблемы с разницей во времени. Действительно, в 1972 году, когда было введено понятие високосной секунды и UTC — Всемирного координированного времени — этот вариант устраивал и научное сообщество, и индустрию информационных технологий той эпохи. Однако сегодня понятно, что обновление времени сильно мешает существующим цифровым технологиям.
Дело в том, что многие компьютерные системы используют протокол NTP (Network Time Protocol) для синхронизации с атомным временем. И когда в 2012 году вместо стандартного перехода 23:59:59 → 00:00:00 с субботы на воскресенье появилась високосная секунда 23:59:59 → 23:59:60 → 00:00:00, по всему миру перестали работать Mozilla, Reddit и LinkedIn, а в Австралии пришлось срочно сажать 400 самолетов.
Високосные секунды плохо сочетаются даже с простыми логическими допущениями, например, что время всегда идет вперед. Допустим, у нас есть алгоритм, который считает время выполнения задачи.
start := time.Now() // 3:04:05.000
event()
end := time.Now() // 3:04:05.010
spent := end.Sub(start) // 10 миллисекунд
Алгоритм запоминает время начала, запускает событие, записывает время конца, а затем просто вычитает время начала из времени окончания. Например, если действие заняло 10 миллисекунд, программа вернет ровно такой ответ.
Этот довольно простой процесс ломается при наличии високосной секунды. Дело в том, что у дополнительных мгновений нет какого-то определенного стереотипа вычислений, поэтому программы обычно просто меняют високосную секунду на 23:59. В итоге эта временная точка считывается дважды, что выглядит как поворот времени вспять. В результате в ответ на выполнение все той же программы машина возвращает 990 миллисекунд с отрицательным значением.
start := time.Now() // 3:59:59.995
event()
end := time.Now() // 3:59:59.005 (really 11:59:60.005)
spent := end.Sub(start) // –990 миллисекунд
Почти 10 лет программисты призывали сообщество отказаться от високосных секунд, и в ноябре 2022 года Международное бюро мер и весов наконец-то приняло это решение. Теперь ученым предстоит определить стандарт времени до 2035 года. Впрочем, это не единственный вопрос времени, с которым человечество столкнулось за последние 10 лет.
Временной апокалипсис
В конце 90-х мир был охвачен паникой: журнал Times вышел с характерной обложкой про конец света, издания выпускали статьи с заголовками «Doomsday 2000» («Судный день 2000»), а США и Россия работали над совместным центром стратегической стабильности, чтобы предотвратить случайные ядерные атаки. Всему виной — одна компьютерная ошибка под названием Y2K или Millennium bug («Ошибка тысячелетия»).
Когда инженеры писали софт для первых компьютеров, они старались максимально беречь ограниченные ресурсы машин. Поэтому даты было решено записывать без указания века. Например, вместо 10.10.1960 фиксировалось 10.10.60. Это позволяло без лишних неудобств сэкономить место на накопителях: в конце концов, в обычной жизни четыре цифры года используются не так часто. Поэтому эта особенность ранних систем стала проблемой только концу 20-ого века.
Отдельные разработчики, компании и даже государства всерьез обеспокоились, что первого января 2000 года компьютеры ошибочно решат, что наступил 1900 год. От нового века и так ждали самых невероятных вещей, а тут еще и возможное отключение электричества, сбой в финансовых системах и ошибки на атомных станциях.
Надо сказать, что проблемы действительно были. Две атомные станции в Японии зафиксировали незначительные ошибки, по всему миру кассовые аппараты пробивали чеки, датированные 1900 годом, а в Дании зарегистрировали столетнего младенца. Ни с чем более серьезным человечество тогда не столкнулось — зато ИТ-компании успели получить свою выгоду от общественной тревоги. Например, выпуская свою Microsoft 98 корпорация отметила, что в новой системе «ошибка тысячелетия» полностью решена. Таким образом пользователям давался дополнительный повод обновить операционную систему.
Проблемы со временем появляются не только с переходом к новому веку — трудности связаны и с началом новой эпохи.
Проблема 2038 года
В полночь первого января 2023 года операционная система Unix отпразднует свое 53-летие. Она появилась в 1970 году, и тогда же начался отсчет так называемого времени Unix.
Время Unix — количество секунд, прошедших с 00:00:00 часов 1 января 1970 года. Например, на 19:29:40 часов девятого декабря оно имело значение 1670603380.
Хранить время в секундах очень удобно: это экономит место, позволяет легко сравнивать даты и, в то же время, быстро подстраивать их под любые другие форматы. Однако с этим способом есть свои сложности. Дело в том, что старые 32-разрядные «операционки» способны считать только до 2 147 483 647. Поэтому 19 января 2038 года в 03:14:08, когда секундное значение достигнет потолка системных возможностей, время некоторых ПО пойдет вспять. Из-за этого компьютеры будут интерпретировать 19 января как 13 декабря 1901 года.
Как и в предыдущей истории, ничего страшного в 2038 году не произойдет. Большинство современных устройств 64-разрядные и могут фиксировать время до 292 277 026 596 года. При этом разработчики «отодвинули» эту проблему и для более старых гаджетов.
В 2020 году вышла версия операционной системы Linux 5.10, которая отодвинула дедлайн по решению этой задачи на 2486 года. В новый вариант ОС были внесены изменения файловой системы XFS, которые и позволили расширить временные рамки почти на пять столетий — они представляют собой рефакторинг кодирования временных отметок и введения inode для обработки времени как 64-битного параметра, который хранит наносекунды.
А значит об этой и других проблемах можно не волноваться — у сообщества еще достаточно времени, чтобы справиться с любыми задачами.