Оригиналът е на Oleg Obleukhov, Ahmad Byagowi
Концепцията за допълнителна (високосна) секунда (leap second) бе въведена през 1972 година от международната служба за изчисление на въртенето на Земята International Earth Rotation and Reference Systems Service (IERS) за извършване на промени в гражданското време, което се базира на координираното универсално време (UTC), поддържано от изключително точни атомни часовници. Земята обаче не се върти с постоянна скорост около оста си – слънчевият ден, макар и неравномерно, постепенно нараства, главно заради приливните сили на Луната, но се оказа, че има и други причини. Тази периодична поправка помага преди всичко на учените и астрономите, понеже благодарение на нея наблюдаването на небесните тела е по-точно. Ако я нямаше UTC корекцията, щеше да се наложи да се правят периодични промени в старото оборудване и предишния софтуер, които са синхронизирани за астрономични наблюдения с използването на UTC.
Към днешен ден, от датата на въвеждане на високосната секунда, UTC бе обновявано 27 пъти.
Високосната секунда може да е била съвсем приемливо решение през 1972 година, когато то е удовлетворявало както научната общност, така и сферата на телекомуникациите, но днес UTC пречи по еднакъв начин и на цифровите приложения, и на учените, които вместо него вече използват TAI или UT1.
Нашата компанията Meta поддържа усилията на индустрията да спре бъдещото въвеждане на високосни секунди и силно препоръчва на всички нещата да си останат на сегашното ниво с 27-те промени. Добавянето на нови високосни секунди вече е рискова практика, от която вредата е повече отколкото ползата и ние сме на мнение, че е време за внедряване на нови технологии, които ще я заменят.
Проблемите
Едни от най-важните фактори, оказващи влияние на неравномерното въртене на Земята е непрекъснатото топене и замръзване на ледовете по върховете на най-високите планини в света. Това явление лесно може да се визуализира като си представим въртяща се състезателка по фигурно пързаляне, която променя и управлява своята ъглова скорост с помощта на своите ръце и длани. Когато тя разперва ръце, нейната ъглова скорост намалява, като по този начин се запазва нейния импулс. Съответно, когато прилепя ръцете към тялото си нейната ъглова скорост се увеличава.
Досега са добавяни само положителни високосни секунди. В самото начало просто се добавяше още една секунда, което водеше до появата на твърде необичаен времеви маркер:
23:59:59 -> 23:59:60 -> 00:00:00
В най-добрия случай този скок във времето ще доведе до срив в програмите и дори до повреда на данните поради странните времеви маркери в хранилището за данни.
Тъй като начинът по който се променя въртенето на Земята непрекъснато се променя, то има много голяма вероятност в бъдеще да получим отрицателна високосна секунда. В този случай времевият маркер ще изглежда по следния начин:
23:59:58 -> 00:00:00
Влиянието на отрицателната високосна секунда никога досега не е тествано в големи мащаби. Това може да окаже наистина разрушително действие на всичкия софтуер, който зависи от таймерите и предварително зададените и програмирани събития.
При всички случаи всяка високосна секунда може да създаде сериозни проблеми на хората, които обслужват съответните хардуерни инфраструктури.
Размазването
Последно време стандартна практика стана ‘размазването“ на високосната секунда във времето чрез обикновено забавяне или ускоряване на таймерите. Не е приет универсален метод за осъществяването на тази идея. Meta например, размазва високосната секунда в рамките на 17 часа, започвайки от 00:00:00 UTC, като необходимата информация се взема от пакета данни за часовите пояси (tzdata).

Нека се спрем малко по-подробно.
Избрахме 17-часовия времеви интервал главно защото размазването се осъществява в Stratum 2, където стотици NTP сървъри едновременно извършват това разтягане. За да бъде разликата между тях приемлива, стъпката трябва да е съвсем минимална. Ако стъпката на размазване/разтягане е твърде голяма, NTP клиентите могат да решат, че някои от тези устройства са дефектни и да ги изключат от кворума, което може да доведе до прекъсвания в работата.
Началният час в 00:00:00 UTC също никъде не е стандартизиран и има огромен брой възможни вариации. Така например, някои компании започват размазването в 12:00:00 UTC предния ден и го разтягат в рамките на 24 часа. Други започват два часа преди събитието, трети стартират процеса точно по време на събитието.
Освен това има най-различни алгоритми за осъществяване на размазването. Има секундна корекция на ядрото, линейно размазване (когато се прилагат равни времеви стъпки), косинусоидално и квадратично (каквото използва Meta). Алгоритмите се базират на различни математически модели и създават различни диаграми на изместването:

Сигналът, който се използва като стартер за осъществяването на прехода при сателитните системи за навигация (GPS, GLONASS, Galileo и BeiDou), е различен. В някои случаи той се транслира до сателитните системи няколко часа преди настъпването на събитието. В други случаи се разпространява в UTC с вече добавена високосна секунда. В различните системи за навигация значението на високосната секунда се различава в зависимост от времето на стартиране на съответната система.

Всичко това изисква нетривиална логика на трансформация в източниците на време, включително нашия собствен Time Appliance. Загубата на сигнал от сателитната система в такъв важен момент може да доведе до загуба на времевия показател за осъществяване на преход и до сериозен конфликт, което може да доведе до дълги прекъсвания в работата на тези спътникови системи.
Също така, информацията за преход се разпространява месеци преди събитието в пакета tzdata, а за феновете на ntpd то е във вид на втори файл, разпространяван чрез уеб сайта на Internet Engineering Taskforce (IETF). Липсата на новото копие на файла може да доведе до пропускане на високосна секунда и също да причини прекъсвания.
Както вече споменахме, „размазването“ е изключително важен момент. Ако NTP сървърът се рестартира именно през този интервал, тогава е много вероятно той да има „старо“ или „ново“ време, което ще се разпространи към клиентите и ще доведе до прекъсвания в работата.
Поради тази неопределеност публичните NTP пулове не извършват размазване и понякога за решаването на този проблем просто подават на своите клиенти съответния показател за осъществяване на преход. SNTP обикновено увеличава стойностите на часовника и по този начин се справя с последствията, описани по-горе. По-умните клиенти могат да изберат стандартната стратегия за локално размазване на прехода. В крайна сметка това означава, че големите играчи от ранга на Meta, които извършват този процес в обществените услуги, не могат да се присъединят към публичните пулове.
Дори след прехода ситуацията остава рискова. NTP софтуерът винаги трябва да прилага отместване спрямо използвания от него източник на време (сателитна навигация, TAI или атомен часовник), а софтуерът на PTP трябва да излъчва така наречения флаг за отместване на UTC в известията.
Отрицателното влияние на високосните секунди
Високосната секунда и създаваното от нея отместване предизвикват проблеми в цялата индустрия. Един от най-лесните начини със сигурност да се предизвика прекъсване в работата е да се допусне, че времето винаги се движи напред. Да предположим, че имаме следния код:
start := time.Now() // do something spent := time.Now().Sub(start)
В някои случаи на използване на spent може да се окажем в ситуация, когато по време на събитието за прилагане на високосната секунда, нейното значение е отрицателно. Подобно допускане ще доведе до множество сериозни прекъсвания в работата. Ситуациите от подобен род са подробно описани в редица технологични статии.
През 2012 година форумът-социална мрежа Reddit претърпя много големи и сериозни прекъсвания в своята работа заради високосните секунди. Сайтът бе недостъпен няколко пъти за по 30-40 минути. Това се случи, когато промяната на времето обърка таймера с висока разделителна способност (hrtimer), причинявайки хиперактивност на сървърите, а това доведе до блокаж на техните процесори.
През 2017 година Cloudflare публикува много подробна статия за въздействието на високосните секунди върху публичния DNS на компанията. Основната причина за грешката, която засегна DNS услугата, бе предположението, че времето не може да се върне назад. Кодът взе неправилни времеви стойности и ги подаде на функцията rand.Int63n() на програмния език Go. Функцията rand.Int63n() с основание показа паника, понеже подаденият аргумент бе отрицателен и това доведе до отказ на DNS сървъра.
Отказът от високосната секунда
Процесът на прилагане на високосните секунди предизвика огромен брой проблеми в IT сектора и продължава да създава най-различни и твърде коварни заплахи. Цялата индустрия се сблъсква със сериозни проблеми, когато стане дума за високосните секунди. И тъй като тези събития са много редки, те всеки път оказват твърде разрушително влияние на обществото. В абсолютно всички сектори изискванията към точността на таймерите стават все по-високи и на този фон високосната секунда създава повече проблеми, отколкото ползва, създавайки безпорядък и прекъсвания в работата на различните онлайн услуги.
Ние, специалистите на Meta, поддържаме предложението на цялата IT общност за отказ от по-нататъшното използване на високосни секунди и искаме да се спрем на сегашното ниво (27), което ще ни стигне за цялото следващо хилядолетие.
Всичко важно от света на технологиите, директно в пощата ти.
С абонирането приемате нашите Условия и Политика за поверителност. Може да се отпишете с един клик по всяко време.
Коментирайте статията в нашите Форуми. За да научите първи най-важното, харесайте страницата ни във Facebook, и ни последвайте в Google Новини, TikTok, Telegram и Viber или изтеглете приложението на Kaldata.com за Android, iPhone, Huawei, Google Chrome, Microsoft Edge и Opera!

